Re: some thoughts about contributing to gnome

[Olav Vitters <olav bkor dhs org>]

On Wed, May 11, 2005 at 09:57:29AM -0600, Elijah Newren wrote:
> On 5/11/05, Vincent Untz <vincent vuntz net> wrote:
> > Le mercredi 11 mai 2005 à 00:49 +0200, Samuel Abels a écrit :
> > > Am Dienstag, den 10.05.2005, 16:25 -0600 schrieb Elijah Newren:
> > > > We've pinged d-d-l a few times about this.  My question to
> > > > you is: do you have any ideas about how we could be more effective at
> > > > getting developers to review patches?
> > >
> > > I am probably going to make myself unpopular, but I would suggest
> > > regular notifications (once per 48 hours) on bugs that have a new
> > > attachment and have not been confirmed. (Implement an automatic "cvs
> > > commit" right remover for those who do not review their product's
> > > patches properly and you also get my vote ;-).)
> 
> Honestly, I don't think unconfirmed vs. new has much use.  We've made
> periodic pushes over the years to try to make it more useful by
> confirming bugs and starting all bugs as unconfirmed and various other
> things, but I've found that it just isn't useful to me even for the
> products I help maintain--and that I almost never bother confirming
> bug reports against those products or even for bugs where I can
> duplicate problems that others have reported.  Personally, I'm
> starting to think that it's just another setting to tweak for the sake
> of tweaking settings, and that all we're doing with it is generating
> bug spam instead of genuinely helping.  Do others get this same
> feeling?

It might not matter for a developer, but for me it is a easy way to see
if someone from bugsquad looked at the bug. Bugzilla 2.18 allows a
developer to not receive bugmail for unconfirmed bugs. I think for
developers that are overworked and when clearly communicated (shows on
the bug, bugsquad knows, etc) it should be possible for a developer to
ignore unconfirmed bugs.

I'd like bugsquad for some products to act like a helpdesk. Bugsquad
gets rid of most stuff.. and confirms it after they are done. This
doesn't mean that the bug is valid.. just that it likely isn't a dupe,
stacktrace looks ok, etc. (in short.. passes the call to someone who
knows more). Ideally bugsquad could do more, but not enough hands for
that.

This means some bugs won't be read by anyone for a longer time, that is
why this should be clearly communicated on show_bug.cgi itself + point
to bugsquad. Users can help by becoming a bugsquad member and hopefully
the bugmail for overworked products/developers can be read normally
again.

> > Sending more mails won't help me: I'm already receiving tons of bugzilla
> > mails and I perfectly know how to find patches in bugzilla. 
> 
> But would it hurt to receive another email every day or two
> summarizing the unreviewed patches in bugzilla?  While it may not help
> you, there are those for whom this would be very helpful (e.g. Havoc
> responds to emails like this when I manually send them to him, but he
> won't go looking for them and he sometimes doesn't have time to look
> at new patches when they arrive but then they become lost in a huge
> inbox.  Honestly, I think it'd help me too).

Btw, I'd like to do this stuff starting with 2.20. Developing more in
bugzilla-new will only make the transition longer (most reports need to
be rewritten, our changes need merging.. + 2.20 has nice things to help
us)

[..]
> > I don't have any real proposition. Maybe we should help newcomers
> > understand how hard it is for maintainers to have all those bugs and
> > deal with them. Or maybe we should have a maintainer status page so
> > newcomers at least know when they'll have an answer: "maintainer is busy
> > right now, he will come back to check your patches on May 22nd"...
> 
> Actually, I was thinking of a product/component status of some type,
> which could appear directly on show_bug.cgi.  Originally, the idea was
> just a maintained/unmaintained status (where nothing is shown if the
> product is maintained but some big warning is shown otherwise--just so
> users or potential new developers know to be patient or even know that
> they should try an alternate means of communication if really
> important), where the state can be set by manual request and/or by
> some automated criteria (e.g. if any product has more than 20% of its
> patches, which were submitted between 14 days and 6 months ago, in the
> unreviewed state then mark the product as unmaintained).  Thoughts?

That was something I wanted to do as well.. sometimes I wonder if I
should respond to these emails or just wait for Elijah to answer ;)

btw (before you suggest this): I also want to do something with the
product specific guidelines.. integrating those more in simple-bug-guide
and show_bug.cgi

-- 
Regards,
Olav