[openbeos] Re: VLC

On 2006-03-17 at 10:19:26 [+0100], Waldemar Kornewald <wkornew@xxxxxxx> wrote:
> Well, I'm not completely rewriting the ticket system (and I'm happy that
> I have not yet really started with coding ;). Collaboa already does much
> of what Trac does. The biggest problem for me is that Trac is written in
> Python. Rails makes it many times easier to develop web apps. But okay,
> here are my Haiku-related issues with Trac (if someone would like to fix
> them, please step in; I could try to help...):

As far as I know Python/Ruby are considered both as good languages for rapid 
development. Ruby on Rails has gained a lot of attention for web development 
but is not without it's detractors: there is no O-R silver bullet and most 
LCD O-R solutions remove responsibility for data management from the 
database. Django is a similar framework for Python and tied more or less to 
PostgreSQL for reasons of data integrity (yeah!). Personally I like to use 
Zope because it's been out there so long there and I'm used to it. 

I agree that standalone developments such as Trac do generally mean more 
work. That said there are lots of very nice things in Trac and some of the 
code is exemplary. Unfortunately most of the DB stuff is a mess because the 
data model is a mess. There is a fundamental question here: should the user 
be modelled within the database even though they may exist only in an 
.htaccess / svn list? My feeling is yes but Trac was built without this in 
mind. Instead there is a session table that stores the .htuser by default and 
runs a check on the related e-mail address. What can I say? An ugly mess but 
RelationalTrac solves this.
 
> Cc field:
> It must not be possible to remove other users from the list. I'd like to
> require users to register and then allow for clicking a "Subscribe"
> button (replacing the Cc field). When someone (*else*) assigns a ticket
> to you an email notification is sent and you are automatically
> subscribed. Everyone who modifies/comments-on/creates tickets is
> automatically subscribed, too.

The best thing is not to use a default cc:. This can be enabled in the config 
file.
 
> When I click the "resolve as:" drop-down list I feel interrupted in my
> work-flow. The list is too long for such a simple action. Nearly all
> resolutions require a comment (e.g.: why will it not be fixed?), so I
> would rather remove Resolution and only have these status values:
> * Open
> * Assigned
> * Closed
> * Duplicate
> * Deleted (add comment on *why*)

I disagree with this. When Tickets are resolved in Trac a comment is usually 
supplied. But you can adjust the values and even actions. RelationalTrac 
limits who can close a ticket.
 
> Only developers and admins are allowed to create tasks. Users may only
> create "defect" tickets. This probably requires permissions per ticket type.
> 
> Only developers and admins must be assignable to tickets (add permission
> role).

Implemented in RelationalTrac and available through the admin plugin. Though 
the underlying permission system in Trac is a mess - functionality is enabled 
by default :-/
 
> Milestone, Priority, and Status (and for ticket creation: Assign-To)
> should only be editable by developers and admins. For normal users the
> drop-down fields should be hidden. TICKET_APPEND is okay to start with,
> but non-editable fields should be hidden instead of just disabling them.
> 
> When creating tickets, next to the description field there should be a
> little text (yes, that's easy to fix):
> -----
> For "defect" reports, please specify:
> * how to reproduce
> * experienced behavior
> * expected behavior
> -----

Just edit the template.
 
> Components should be organized as a tree instead of a flat list.

This is more of a challenge but not impossible. Already done most of the work 
in RelationalTrac with reference to versions - not all components are 
available in a particular version.

> Severity and Keywords should be removed (it's customizable, so that is
> not a big problem...).
> Hmm, maybe Keywords could replace the component tree, but they should
> only be editable by developers and admins. For the future, there should
> be a keyword selector and the values list should adapt to the currently
> selected component. Guys, what do you think about using keywords? I
> would not have a problem with that.

Keywords are in their for the tag-mad gmail bloggers out there... ;-)
This, however, has nothing to do with a hierarchical component structure.

> Admins should be allowed to save queries for reuse by others (I'd like
> to disable reports and the wiki) and the default query should list open
> tickets categorized by milestone.

This is pretty much the idea behind the reports section so already possible. 
Wiki's and reports are controlled by permissions. Well, you pretty much must 
enable Wiki reading to use Trac. Of course, users should not be allowed to 
deface it.
 
> If you are creating a task or enhancement/wish there should not be a
> Version field (hide it). I find this extremely confusing! Since only
> developers can create tasks, this is a minor issue, though.

This might be the case for Haiku at the moment but a correct version or build 
number is essential when bug hunting. It's probably easy enough to use a 
default version for new bugs.
 
> The wiki is not needed. If the svn plugin does not yet work with remote
> repositories then we can live without it.

Just think of the wiki as the place to put text about the bug tracker. A 
mini-CMS for the admins. I'm not sure what you want to be able to "live 
without"? I think svn integration is one of the key advantages of Trac but I 
can agree that a bug submission and tracking system can work without source 
code integration.
 
> Is MySQL support finally working?

Is MySQL finally working? ;-) Which flavour of MySQL do you mean? Anything 
other than InnoDB (developer now with Oracle) or better MaxDB and you're just 
as badly off sticking with SQLite. Any such system should have a reliable 
RDBMS underpinning with proper support for data integrity so I would run Trac 
with PostgreSQL or equivalent.

> Help would be greatly appreciated! I might have a look at Trac, again.
> Maybe I can hack something up (I've never used Python, only read some
> tutorials)...

We should probably take further discussion off this list. With myself and 
Mikael there are two non-Haiku developers with Python and Trac experience. 
The Trac developers are a good bunch but it is usually better to talk to them 
on IRC than on the list - I signed off after seeing an RMS quote in someone's 
signature *all the time*.

Charlie

Other related posts: