Re: bugzilla practices

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Wed, Feb 22, 2012 at 8:05 PM, Roland McGrath <roland@hack.frob.com> wrote:
> I would still like to see some more development on bugzilla practices.
> In no particular order:
>
> 1. UNCONFIRMED
>
> ? What about starting to use UNCONFIRMED as the initial state and having
> ? triagers change to NEW after reproducing the problem, weeding out user
> ? error, requesting obvious missing information from the reporter, etc?
>
> ? What I have in mind is that we may have two distinct classes of people
> ? who look at bugs:
> ? * developers, who intend to fix bugs but want to focus their time on the
> ? ? actual debugging
> ? * triagers, who want to help but may lack the expertise to actually fix
> ? ? many bugs
>
> ? So developers with limited time who want to maximize the use of their
> ? rare expertise would look at NEW bugs but not UNCONFIRMED ones.
>
> ? This notion is only useful if we get a significant active team of
> ? triagers. ?But that's something we could really use.

This sounds like a great idea.

Is the sufficient concensus to add it to the wiki under bugzilla/procedures?

> 2. Recruit a triage team!
>
> ? This is http://sourceware.org/ml/libc-alpha/2005-10/msg00057.html
> ? but >6 years later, and this time with feeling.
>
> ? IMHO this can be an excellent entry point for new contributors to the
> ? project. ?It can be pretty easy to ramp up and does not require much
> ? prior expertise or experience. ?The work comes in tiny bite-sized
> ? morsels, so doing a tiny bit every day helps and doing big spurts from
> ? time to time helps, whatever fits in with a particular person's life.
> ? It trivially scales to roughly arbitrary numbers of people pitching in.
>
> ? http://sourceware.org/glibc/wiki/Bug_Triage is already a fairly decent
> ? introduction. ?Perhaps it could be improved, or made more friendly and
> ? inviting. ?I don't know what would work to drum up volunteers. ?Maybe
> ? some pleas on libc-help? ?Elsewhere? ?Someone could become a "glibc
> ? ambassador" and go wherever people go to find volunteers for things?

I agree that this is a great idea, but I think we need a very *very*
clear goal with the triage. That goal is then communicated to the
volunteers and we set off to meet that goal and stop when we accomplish
it and give everyone a pat on the back :-)

For example:
- Call it a "Welcome the bugs" party or something pithy.
- Using trunk confirm 10 bugs that in the UNCONFIRMED state either
e.g. UNCONFIRMED=>NEW.
- Post questions about a bug your working to confirm on libc-help
where we can mentor.
- Complete goal, pat on back, list it on the website as news.

Pre-party work:
- Find and mark 10+ bugs as UNCONFIRMED.

> 3. Mandatory bugzilla filing for user-visible bugs
>
> ? I think we should get to a system where (at least) every bug that might
> ? have affected an end-user is filed in bugzilla.

Agreed.

> 4. Auto-annotation on git commits
>
> ? We used to have this under CVS, based on regexp matching of the
> ? ChangeLog [BZ #nnn] convention. ?We should get someone to figure out
> ? implementing that for git now. ?(I'm inclined toward doing it based on
> ? the ChangeLog diff in the commit as we did for CVS. ?But we could also
> ? do it based on a convention for BZ# tags in commit log messages if that
> ? is greatly easier to implement.)

Sounds like a nice thing to do...

> 5. Formalize out how bugzilla use relates to release branches
>
> ? I think Carlos may already have pretty much settled on this.
> ? But how we do it is not really clear to me from reading the wiki page.

I do have some strong thoughts here and I'll write it up in the wiki soon.

The harder question, as Joseph mentions, is how to decide on 2.16 and how
to execute on that.

> That's all that is popping to mind just now. ?But I think it's worthwhile
> in general to try to evolve in the direction of whatever other such
> formalisms people think of either that make bugzilla itself a more useful
> resource for users, triagers, or developers, or that make workflow smoother
> and nicer for developers and triagers.

What are we doing with issue flags?

Are they usefull?

Confusing?

Should we remove them?

For example we have the following flags:
backport
examined
testsuite

Can we avoid the complexity of 4-state flags and just use keywords to
tag things?

Cheers,
Carlos.