"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
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
