[haiku-development] Re: Modifications to Trac ticket fields

Hi Niels,

"Niels Reedijk" <niels.reedijk@xxxxxxxxx> wrote:
> I hope that after some initial roughness (in terms of speed), you are
> liking (or at least not disliking) the Trac source code and changelog
> browser. If you haven't tried, try http://dev.haiku-os.org/browser 
> and
> http://dev.haiku-os.org/log to check it out.

I definitely like it, and thanks for your time and effort - it's just a 
bummer that it's not up-to-date with the actual repository. Would it be 
possible to have the changelog/x link fall back to the repository 
browser at BerliOS in case Trac doesn't know it yet?
How often is the Trac repository updated, btw?

> First of all, the 'platform' field. It is not a default field in 
> Trac,
> we added it for a reason which I guess is a hope for multi-platform
> support. Currently the division of tickets among them is:
> All: 368
> PowerPC: 2 (requests for implementation of these platforms)
> x64: 2
> x86: 39
> None: 20
> 
> The question currently is whether this is a useful field right now or
> not. The bug reporter suggests adding the virtual platforms to this
> list (at least, this is how I interpret the request). The other 
> option
> is just to remove this custom field. What do you think?

Bugs can be restricted to a certain platform as they can be restricted 
to certain component.
Since it's not unlikely that there are different people in charge for 
the same component on different architectures, I'd vote for keeping it.
It might not be that useful right now, but the number of platforms 
Haiku will run on will definitely increase over time.

> The other suggestion is to add a SVN revision field. As long as we're
> using the bug tracker to track bugs in the trunk, we might as well 
> add
> it as it is a relevant piece of information. The question is, should
> this field reflect the latest tested revision, or the revision in
> which the bug was first encountered? I prefer the second option,
> because it gives both developers and testers an easy overview of bugs
> that need to be tested again for eventual fixes. In the ticket
> details, the history of this field is saved, so it can be easily
> tracked at which revision a bug was reported.

Usually, the second information is unknown, though. While I'm in 
general pro adding this field, I'm not sure if it's a good idea to 
actually do it, given that it's ambivalent in the sense you're 
describing above, our current bug reporters are pretty good at adding 
that information, too :-)

Bye,
   Axel.

Other related posts: