[ros-dev] Bugzilla interface

[Javier Agustìn Fernàndez Arroyo]

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 <elhoir at gmail.com>

> "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 <aleksey at reactos.org>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" <timo.kreuzer at web.de>
>> Sent: Friday, August 27, 2010 7:20 PM
>> To: "ReactOS Development List" <ros-dev at reactos.org>
>>
>> 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
>>> Ros-dev at reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev at reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.reactos.org/pipermail/ros-dev/attachments/20100827/5dc06ec3/attachment-0001.htm>