Bugzilla interface

[Timo Kreuzer]

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

[Ged Murphy]

Or consider a move to fogbugz?
It's not open source, but it's a lot better at bug tracking.
I'm not sure whether the db can be converted, so it might be a dead end
anyway.

Ged.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Timo Kreuzer
Sent: 27 August 2010 16:20
To: ReactOS Development List
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
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Aleksey Bragin]

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" [e-mail]
Sent: Friday, August 27, 2010 7:20 PM
To: "ReactOS Development List" [e-mail]
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
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Javier Agustìn Fernàndez Arroyo]

"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 [e-mail] 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" [e-mail]
> Sent: Friday, August 27, 2010 7:20 PM
> To: "ReactOS Development List" [e-mail]
>
> 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
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[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 [e-mail]
> "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 [e-mail]:
> > 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" [e-mail]
> > Sent: Friday, August 27, 2010 7:20 PM
> > To: "ReactOS Development List" [e-mail]
> >
> > 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
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

Why?
Please tell me you aren't a freetard.
closed source software is better than open source 99% of the time.

2010/8/27 Javier Agustìn Fernàndez Arroyo [e-mail]
> "Or consider a move to fogbugz?
> It's not open source"
>
> IMHO if its not open source, its (or should be) automatically discarded

[Javier Agustìn Fernàndez Arroyo]

"Please tell me you aren't a freetard."
sorry, i am :P
why do you think i follow ROS development? :)

and, im not lawyer, so i cant tell if using closed software for developing
an open source one is legal or nope, but i think its the best way for making
a really "free" software, using absolutely free tools

On Fri, Aug 27, 2010 at 7:29 PM, Ged Murphy [e-mail] wrote:
> Why?
> Please tell me you aren't a freetard.
> closed source software is better than open source 99% of the time.
>
> 2010/8/27 Javier Agustìn Fernàndez Arroyo [e-mail]
> > "Or consider a move to fogbugz?
> >
> > It's not open source"
> >
> > IMHO if its not open source, its (or should be) automatically discarded
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

2010/8/27 Javier Agustìn Fernàndez Arroyo [e-mail]
> "Please tell me you aren't a freetard."
> sorry, i am :P

oh dear....
> why do you think i follow ROS development? :)

Yeah, because reactos is sooo much better than windows.
> and, im not lawyer, so i cant tell if using closed software for developing
> an open source one is legal or nope,

It's definitely not
> but i think its the best way for making a really "free" software, using
> absolutely free tools

So you'd be against most devs wish of moving to closed source sortware, like
msvc.
You should follow GNU/linux, you'd absolutely love it!  ;)

[Javier Agustìn Fernàndez Arroyo]

"You should follow GNU/linux, you'd absolutely love it!  ;)"
Actually im writting this into Ubuntu right now :D

On Fri, Aug 27, 2010 at 7:43 PM, Ged Murphy [e-mail] wrote:
> 2010/8/27 Javier Agustìn Fernàndez Arroyo [e-mail]
> > "Please tell me you aren't a freetard."
> > sorry, i am :P
>
> oh dear....
> > why do you think i follow ROS development? :)
>
> Yeah, because reactos is sooo much better than windows.
> > and, im not lawyer, so i cant tell if using closed software for developing
> > an open source one is legal or nope,
>
> It's definitely not
> > but i think its the best way for making a really "free" software, using
> > absolutely free tools
>
> So you'd be against most devs wish of moving to closed source sortware,
> like msvc.
> You should follow GNU/linux, you'd absolutely love it!  ;)
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[James Holland]

I know you will all say who is this random dude on our mailing list, but I
had a strange urge to email.

I suggets looking at the price of fogbugz
http://www.fogcreek.com/FogBugz/PriceList.html

1 license per person who would have a "case" assigned to them.

http://www.fogcreek.com/FogBugz/PriceList.htmlLicensesFogBugz
(standalone)Kiln &
FogBugz http://www.fogcreek.com/FogBugz/Bundle.html1 License$299$3595
License Pack$999$1,19910 License Pack$1,899$2,29920 License Pack$3,499$4,19950
License Pack$7,999$9,599Site License
(unlimited users on a single installation)$9,999$11,999

OpenSource aside, if you were to move to fogbugz it would lock you in for
the most part. If you expanded to have more than 10 developers you would
have to fork over another $1800.
I don't know ReactOS's budget, but do you have a couple $1000 to spend right
now on bug tracking software?

2010/8/27 Javier Agustìn Fernàndez Arroyo [e-mail]
> "You should follow GNU/linux, you'd absolutely love it!  ;)"
> Actually im writting this into Ubuntu right now :D
>
> On Fri, Aug 27, 2010 at 7:43 PM, Ged Murphy [e-mail] wrote:
> > 2010/8/27 Javier Agustìn Fernàndez Arroyo [e-mail]
> > > "Please tell me you aren't a freetard."
> > > sorry, i am :P
> >
> > oh dear....
> > > why do you think i follow ROS development? :)
> >
> > Yeah, because reactos is sooo much better than windows.
> > > and, im not lawyer, so i cant tell if using closed software for
> > > developing an open source one is legal or nope,
> >
> > It's definitely not
> > > but i think its the best way for making a really "free" software, using
> > > absolutely free tools
> >
> > So you'd be against most devs wish of moving to closed source sortware,
> > like msvc.
> > You should follow GNU/linux, you'd absolutely love it!  ;)
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
-- 
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom it is intended to be
sent, and may contain information which is privileged, confidential or
otherwise exempt from disclosure under applicable law. This message contains
confidential information and is intended only for the individual named. If
you are not the named addressee you should not disseminate, distribute or
copy this e-mail.

[Olaf Siejka]

"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