This is the mail archive of the
mailing list for the glibc project.
Re: call for assistance: glibc bugzilla triage
- From: Dwayne Grant McConnell <decimal at us dot ibm dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Mon, 24 Oct 2005 16:06:11 -0500 (Central Daylight Time)
- Subject: Re: call for assistance: glibc bugzilla triage
- References: <20051023030137.9DD371809AD@magilla.sf.frob.com>
On Sat, 22 Oct 2005, Roland McGrath wrote:
> Quite some time ago, GOTO Masanori volunteered to do bug triage for glibc.
> We are very grateful to him for those efforts. The work is always tedious
> and often thankless, and can easily be very time-consuming especially for a
> single person to cope with. This lone volunteer has not been able to spend
> all the time it would take to consistently handle the load. Recently
> Ulrich Drepper asked me to change the default bugzilla owner to himself,
> because the efforts volunteered to date have not kept up with the need.
> Ulrich and some other libc developers do some occasional spurts of plowing
> through reports. But their time is really better spent fixing the problems
> that have been verified, not sifting through reports to find them.
> I am asking for a new, sustained, coordinated contribution of efforts to
> make glibc bug tracking much better. If you care about glibc or about its
> users, if you rely on glibc's code for your business, please contribute to
> managing its maintenance. This is what we need. Individual volunteers are
> great, but understandably they can rarely stick it out doing the
> unenjoyable, dull work that must be done continually. For every person who
> volunteers and helps, I am grateful for every spare hour they do put in--my
> heartfelt personal thanks especially to anyone who helps with the unfun
> admin stuff and aggravating bug triage. In particular since I find it so
> onerous myself, I could never ask these individuals to do even more of it.
> (If you can hack some code or write some documentation and that's more fun
> a way to contribute to the project, then for goodness sake, do that!)
> Organizations that use glibc, that package glibc, that work on glibc and
> want to contribute to its development, should expect to put some resources
> back into the project, even into the project "overhead"--not just fixing
> bugs that matter to you. This means allocating paid time of people to help
> the project on the tedious work of bug triage and release management that
> has to be done for the good of us all. Pitch in, and I'll sing your praises!
> I hope to see a team of people (supported to do it if they are not saints)
> take responsibility for handling glibc bugzilla reports as they come in, to
> filter them into reasonable verified problem reports for developers to work
> on, to track that the problems get fixed, that the fixes get verified
> against the reporter's test cases, that the fixes get merged onto release
> branches and verified there, and that reports don't fall through the
> cracks. I don't expect a repeat attempt for a single volunteer to do it
> all to be viable, saints notwithstanding. The work should be done steadily
> on a daily and weekly basis, and no one person can be expected to have it
> all pile up on their head. I would love to see some organizations state in
> no uncertain terms their commitment to contribute labor resources to the
> bug management effort, specifically to form a team to be responsible for
> bug tracking. I'm talking fancy, but the "resources" required are really
> just a few hours a week from several people. What's needed is the
> commitment to allocate that time consistently and stick it out with a
> sustained cooperative process that keeps going.
> I am eager to facilitate such new efforts however I can. They require
> other people to step up and take charge of making it happen--that's what
> this plea is about. (I am already the release manager, among other things.)
> I just speak my mind without consulting anyone, and can be contradicted any
> time, but I'll assert that here I'm speaking on behalf of the core glibc
> developers and the glibc steering committee. Thanks for your attention to
> my rants, and for your contributions, past, present, and future, to glibc.
I would be willing to contribute on bugzilla triage but I doubt I could do
as well as GOTO by myself. However, I'm not completely sure I understand
what is or is not expected. So making a list of possible tasks from the
paragraphs above I see
1. handling glibc bugzilla reports as they come in
2. to filter them into reasonable verified problem reports for developers
to work on
3. to track that the problems get fixed
4. that the fixes get verified against the reporter's test cases
5. that the fixes get merged onto release branches and verified there
6. and that reports don't fall through the cracks.
Should I just dive in and try to handle a bug or is there more I should
know about what is expected?
Also, if multiple people are doing this would will be the default bugzilla
owner? Should I just assign bugs I'm working on to myself?
> I don't expect a repeat attempt for a single volunteer to do it all to
> be viable, saints notwithstanding. The work should be done steadily on
> a daily and weekly basis, and no one person can be expected to have it
> all pile up on their head. I would love to see some organizations state
> in no uncertain terms their commitment to contribute labor resources to
> the bug management effort, specifically to form a team to be responsible
> for bug tracking. I'm talking fancy, but the "resources" required are
> really just a few hours a week from several people. What's needed is
> the commitment to allocate that time consistently and stick it out with
> a sustained cooperative process that keeps going.
Dwayne Grant McConnell <email@example.com>
Lotus Notes Mail: Dwayne McConnell [Mail]/Austin/IBM@IBMUS
Lotus Notes Calendar: Dwayne McConnell [Calendar]/Austin/IBM@IBMUS