"First I think it would be very useful, if we could edit the description
field of the bugs. This way we don't need to browse through dozens of
comments to find all neccessary info, while the description only contains
useless stuff. This should be restricted to the original reporter and
testers / developers. Then when filing a new bug or looking at a bug that is
already filed, the layout is horrible. I'm not a webdesigner, so it's hard
for me to say how it should look like, but definately not the way it is.
This might be appropriate for projects whose website look like
http://www.gnu.org/software/binutils/ but I'm sure, we can do better."
Agreed.
- Reporter: indeed, this one should be filled in automagically.
- Component: IMO, this field is necessary, maybe not precisely like the
current on, but still. Patches can be taken away from there, replaced by
PATCH tag. ARWINSS should be moved to product in my opinion, as it doesnt
fit there either. As for the rest, we need some generalized cathegory we can
divide bugs into, at least for sorting/listing. Without it, how we shall
separate drivers bugs from kernel's? We could use separate tags for each
component as a rule, but then listing userland bugs would require a filter
that is several lines in lenght, as well as manually updated with every
change. I agree that win32 is too general, it could be split up a bit, but
i`m against removing this field completely.
- Severity: agreed, it should be set automagically;
- URL: i considered using it to hold Tags, but a dedicated field for a
download addres of given application is also usefull. Hence i do not agree
here
- Alias: You dont like misusing it, but just a bit above you propose
misusing URL field on the same basis as we do with Alias? We dont have much
bugs sharing the same regression revision, and even when that happened, we
can easily avoid it but adding small trailing chars, like dots or lines.
First of all, it works, as you can see here:
http://www.reactos.org/wiki/Buglist - secondly, we need to store regression
revision in some separate field, and we cant mix it up with Tag field. We
can remove this field from New bug entry and have it editable only by devs
and testers, but it has to stay like this until better solution is found.
- Summary&Description: as long as the proposed changes are logical and i
agree with them, didnt those interfere with bugzilla code too much? If such
changes are not causing much problem, why dont we redesign bugzilla's fields
and adopt them to our precise needs, with precised field's description? I've
been told that we shouldn't change buzilla too much, as it will be difficult
to update it to new releases in the future. Can someone speak up regarding
this problem and decide once and for all what can be done?
Gabriel and I are preparing some changes to bug reporting and tagging. What
Timo listed above, is part of our designed 1st class tags:
PATCH, METABUG, TRANSLATION, REGRESSION, HACK, UNIMPLEMENTED, ARWINSS, TAG,
but i will discuss them in a separate mail.
Best regards