Re: [PROPOSAL] Origin and Bugs support
On Mon, 27 Nov 2000, Britton wrote:
>
> > > > Origin: Debian
> > > > Bugs-To: mailto:apt@packages.debian.org
> > > >
> > > > Which is clearly entirely reasonable and legitimate.
> > >
> > > No, it's not. If you want to make a package special instead of making it
> > > an integral part of Debian change the Origin tag.
> >
> > What? It comes from Debian and has an alternate bug location. What exactly
> > is wrong with that? So what should I use for an origin tag in this case?
>
> Wouldn't having reports go to an alternate location prevent the report
> from going into the official bts? This happening seems to be what you are
> arguing against here:
Would it be technically feasable for a VAD (value-added distributor) to
be able to tee a bug report, that is have it go to them, AND go to Debian
with a flag stating that the VAD also has the bug? This way, the VAD can
have first dibs on the bug (for customer relations, or other reasons; to
filter out any issues that might deal with their redistributing) and then
make the bug 'active' for Debian after a reasonable amount of time without
additional traffic from the VAD.
For this to work, I suspect that the bug reporting tools used would need
some explicit way to correalate between each other. The bug # need not be
the same between VAD and Debian.
Quick example:
Joe Luser installes Storm Linux, then finds a bug on a Debian-native
package that only misbehaves when called with a certain set of valid
options, that a Storm-native package happens to call. Storm gains priority
over the bug for X amount of time, but the bug is mirrored on Debian's BTS
from the start, and is transfered to Debian control if the bug is not
dealt with by Storm in the alloted time.
Benefits:
If the bug involves the interaction between a Debian package and a VAD
package, where the Debian package has been determined by local
troubleshooting to be at fault, both systems are notified of the bug AT
THE SAME TIME, VAD has the primary contact with the end admin/user (unless
it defaults), and both Debian and VAD are given an explicit opportinity to
collaborate on this particular bug.
The VAD becomes the first line of technical support to the end admin/user.
Debian still has full access to the bug report in a timely manner.
Liabilitys:
Extending the bug tracking system to support this feature will make it
that much more complex.
The length of timeout for a bug to default to Debian is a Magic Number.
It is possible for the VAD to not share the bug with Debian.
IFF the Experts feel it is feasable to extend the bug system in this
manner, I suggest it be made a release goal for Woody or Woody+1.
Reply to: