Re: Getting Bugzilla support into Bug-buddy
- From: rms39 columbia edu (Russell Steinthal)
- To: Martin Baulig <martin home-of-linux org>
- Cc: Alan Cox <alan redhat com>, mjs eazel com (Maciej Stachowiak), gnome-hackers gnome org
- Subject: Re: Getting Bugzilla support into Bug-buddy
- Date: Wed, 07 Feb 2001 00:10:34 -0500
On 06 Feb 2001 19:29:23 +0100, Martin Baulig wrote:
>rms39 columbia edu (Russell Steinthal) writes:
>
>> Unless Bug Buddy is taught how to automagically pick the correct
>> bugtracker for a package (and I somehow doubt that will work
>> correctly, at least at this stage), I would hate to see us push *any*
>> of the packages out of bugzilla.gnome.org. It will just result in
>> lost or misfiled reports, and probably a few conspiracy theories
>> about trying to push small projects out of GNOME. :)
>
>Rejecting such bug reports (and even silently dropping them if the sender's
>system is misconfigured (no valid email address)) is the only way to do it.
>
>Look at the current situation in bugs.gnome.org; such bugs are currently
>accepted by the system but nobody ever looks at them. They're just slowing
>the whole system down and eating up resources.
Somewhere along the line, things got confused- I'm not sure if it was
my response to Alan or Martin's response to me, but they're confused.
:)
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
> that is that there are not enough people working on gnome
> infrastructure/site admin to keep up with the demands of these
> because most folks are busy working on their rival Ximian or Eazel
> projects and so the number of effective actual gnome core>
> contributions has dropped massively rather than risen as might
> originally have been expected. It may thus be that sourceforge is a
> better place to manage those bug trackers.
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.)
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
reality, many commercial teams may keep their bug-tracker in-house,
but I think it's good that we make an open bug-tracker available. I
happen to think the same about cvs.gnome.org, but this is the issue
at the moment. And if current hardware can't handle it, I think this
is precisely the sort of thing that Foundation money should be used
for. That being said, if the issue is admin time, there's not so
easy an answer.
Beyond that, I agree with most of what you said: GNOME Bugzilla
should certainly reject (with an intelligent auto-reply) bugs for
packages with their own trackers. We can reject non-GNOME bugs that
we can detect programatically (the ones which get sent to valid
packages but turn out to be non-GNOME can be resolved NOTGNOME).
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.
I hope this clarifies my position- if not, I'll try again. :)
-Russell
--
Russell Steinthal Columbia Law School, Class of 2002
<rms39 columbia edu> Columbia College, Class of 1999
<steintr nj org> UNIX System Administrator, nj.org
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]