Re: I think we need this (implemented) bugzilla feature
- From: Mark Gordon <mtgordon ximian com>
- To: Colm Smyth <Colm Smyth Sun COM>
- Cc: mtgordon ximian com, mjs eazel com, sam uchicago edu, gnome-hackers gnome org
- Subject: Re: I think we need this (implemented) bugzilla feature
- Date: Wed, 2 May 2001 19:08:05 -0400
On Wed, May 02, 2001 at 11:49:12AM +0100, Colm Smyth wrote:
> >From: Maciej Stachowiak <mjs eazel com>
> >Mark Gordon <mtgordon ximian com> writes:
> >
> >>
> >> Maybe if there were a way to specify a central machine that would then
> >> route the bug to a bts that you can some how specify. I'm picturing
> >> a bug transfer agent or something of the sort.
> >>
> >
> >It seems like overkill to insert another server into the system just
> >to dispatch transferred bugs to the right location. It would probably
> >be simpler to just hack bugzilla to let you specify what other
> >bugzilla instance to transfer the bug to on a case by case basis.
> >
> >Another problem is that the Red Hat, Eazel, Ximian, GNOME, AbiSource
> >and Mozilla bugzilla instances do not all use the same set of fields
> >or the same valid values for all fields; I imagine the bug transfer
> >feature is not designed with this in mind.
>
> Maciej makes an excellent point here. I think it would be better to have:
>
> - a configuration mechanism that identifies the appropriate bug-tracking system
> for bugs in each GNOME module
One of the problems with this, at least from my standpoint, is that it's
difficult to automate the process of telling a packaging bug from an
upstream bug. It might be good to query the package (assuming it's installed
from a package, and assuming the database isn't locked) to find out where
it came from. Bugs should probably go to the packager first, and if it's
not a packaging bug (or a duplicate), it should then get migrated to an
upstream bugzilla. But since it's not fair to make package maintainers
assume repsonsibility for chasing down packaging bugs (see previous thread
regarding distro-specific patches), this seems like the most reasonable
approach.
-Mark Gordon
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]