Re: Getting Bugzilla support into Bug-buddy



Just a quick note.

> My response was intended to reply to Alan's statement that:
> 
> > The other question to go with this is whether a lot of the 'fringe'
> > projects that merely happen to be gnome.org projects ought to get
> > gently nudged out of the core gnome bugzilla. The reason for saying
> 
> I have no problem rejecting bug reports for non-existant packages, at
> least as long as the auto-response provides some useful information on
> how the user can find the right package.  (Although I also think we 
> might consider seeing if we can find a volunteer to go through the 
> general category and reassign bugs--- that's precisely the type of 
> thing that an eager new contributor could do, without a whole lot of 
> technical knowledge.  If so, we could accept them.)

I had a go at this. I've closed over a thousand bugs in bugs.gnome.org,
I think! The depressing thing is seeing the total stand still for a day 
and then shoot up! Kjartan and a bunch of others have also done a lot
of trimming and reassigning. You're right that it's exactly what eager
new people can do. It's just a long task, but 90% of it can be done
without too much technical knowledge. 

But the person who has done most of this is gmorten (terra diku dk)
who is not, so far as I am aware, on this list at all. He has a slew
of scripts which grep for package names, reassign them, close them
with "the correct place to send this report is..", finds package
names through the top of stack traces ("core generated by:"), and
all manner of things.

He's been running these on incoming bugs to bugs.gnome.org all along.
(He really should be in this discussion, too, because he has stats
and figures and numbers.)

Those scripts have assigned, reassigned or closed thousands of bugs.

> What I do have a problem with is removing packages from
> bugzilla.gnome.org because they are on the "fringe" of the release:
> bug zilla.gnome.org is a community resource, and I happen to think it
> should be available to any GNOME application which wants it. In 

Ah. See. Some of them have their own bug-trackers and don't use Gnome's.
A classic example is abiword which has a big bugzilla at 
http://www.abisource.com/bugzilla/index.phtml -- and yet there were
hundreds of bugs dating back a year or more in bugs.gnome.org. For
AbiWord, abi-word, abiword, abisource and typos thereof. That's the
kind of thing where we should contact the team and ask "should bugs
go here or there?"

Evolution and Nautilus are also good examples just because they already
have bugzillas associated with them which are in use.

Then there's enlightenment, for which we still receive bugs. The
only place I know to report e bugs is the e development mailing list,
and I'm not sure how much they'd appreciate a dozen reports a day :)

Those are good candidates for this.

> About the only part I'm unsure of is rejecting bugs for valid 
> packages with inactive maintainers; it would seem like a good idea to 
> at least track those bugs if we think there's a chance a new 
> maintainer will be chosen/appear, but I'm not sure this happens at 
> all.

Put it this way: if we don't collect those bugs, any new maintainer
is not going to know where to start :) 

Telsa


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]