and, i dont think bugzilla needs a change... i do like as it is shown now.. but its just an opinion...
2010/8/27 Javier Agustìn Fernàndez Arroyo <[email protected]> > "Or consider a move to fogbugz? > It's not open source" > > IMHO if its not open source, its (or should be) automatically discarded > > > On Fri, Aug 27, 2010 at 6:04 PM, Aleksey Bragin <[email protected]>wrote: > >> It would be interesting to listen to Amine's and testers (e.g. Olaf and >> Gabriel) opinion regarding these comments, since they deal with it mostly >> every day. >> >> >> WBR, >> Aleksey Bragin. >> >> -------------------------------------------------- >> From: "Timo Kreuzer" <[email protected]> >> Sent: Friday, August 27, 2010 7:20 PM >> To: "ReactOS Development List" <[email protected]> >> >> Subject: [ros-dev] Bugzilla interface >> >> Hi >>> >>> I'd like to propose an overhaul of our bugzilla interface. The reason is >>> that the current interface is ugly and confusing and I think we can make >>> filing and handling bugs less unenjoyable ;-) >>> >>> 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. >>> >>> Then when filing a bug there are the following fields: >>> >>> - reporter - I know who I am, so why show it to me? Unneccessary >>> - Component: I don't think this field is really useful as it is. First: >>> Patches are definately not a component. Then it's often hard to tell >>> where the bug is. for example, if rapps doesn't download anything, is >>> that related to network or is it a kernel bug or win32 or rapps or is >>> only the server down? You often don't know it when filing a bug. Also >>> win32 covers a lot from win32k to shell32, but are these more closely >>> related than drivers and networking? >>> - Severity: while I think this field is useful and important, it should >>> only be editable by testers and developers and should not appear when a >>> bug is filed. >>> - Platform: should be removed >>> - OS: should be removed >>> - AssignTo, Cc: rarely used on first filing, should IMO only be editable >>> by testers / developers >>> - URL: While we use this field from time to time, I think the URL could >>> as well, if neccessary be put into the description field (provided, it >>> was editable). This versatile field should imo change it's purpose from >>> URL to TAG. So we can add different tags, like REGRESSION, PATCH, HACK, >>> that are currently put into the summery field. It could also contain the >>> regression range or guilty version >>> - Alias: we don't use this, or rather currently only misuse this for the >>> guilty version, which is problematic, as soon as 2 bugs have the same >>> guilty version, IMO unneccessary >>> - Summery: should be as wide as the description field >>> - Description: To get better bugreports, I suggest dividing this field >>> into "Steps to reproduce:" "Experienced behaviour:" "Remarks" >>> These fields can very well be automatically merged into one field, It's >>> just to show people that they must provide steps to reproduce, instead >>> of writing dozens of lines about their hardware configuration and how >>> they feel about the bug. >>> >>> >>> Regards, >>> Timo >>> >>> >>> >>> _______________________________________________ >>> Ros-dev mailing list >>> [email protected] >>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >> >> >> _______________________________________________ >> Ros-dev mailing list >> [email protected] >> http://www.reactos.org/mailman/listinfo/ros-dev >> > >
_______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
