Bugs for daily build packages

[James Westby]

On Tue Dec 08 08:13:00 +0000 2009 Jonathan Lange wrote:
> On Tue, Dec 8, 2009 at 4:37 AM, James Westby <jw+debian at jameswestby.net> wrote:
> > We should ensure that the apport report includes an Origin that
> > can be mapped back to the PPA. Possibly also put [ppa:something]
> > at the start of the subject too.
> >
> 
> I've added a note about this to the wiki.
> 
> How would we do that? Which code base do we need to change?

Probably just apport. Hopefully we will be able to do better than
including the PPA display name, as that may be subject to impersonation
attacks.

> > It would also lead to gardening
> > problems on LP too.
> >
> 
> Really? Such as?

You would end up with a task on an LP project that was just there for
forwarding purposes. Unless we were able to just have the one task
with the bugwatch, that would be fine.

> > The question of what happens if the people getting the bugs don't
> > want them is a good one, and something we should discuss further.
> >
> 
> OK, let's do that.
> 
> My hunch is that for many such PPAs, there won't be all that many bugs
> filed,  so it won't be a problem. For certain PPAs, there will be a
> massive flood. In those cases, the Flooded need to be able to:
>   - identify the source
>   - contact the owner of the source and ask them to switch off the hose
>   - have an obvious court of appeal if the owner of the source won't do that

Sounds about right.

This brings up another issue in my mind. That we run a whole infrastructure
for duplicating bugs ”server side” for Ubuntu. If we are pushing these bugs
to external trackers they won't have that. This means that if they include
a crasher on start in an application with a lot of daily users they will
be submerged by the flood for a day, and have to do a lot of duplication
by hand.

We could look at doing retracing client side, assuming we have debug archives
available, but we can't do dupe detection against arbitrary bug trackers
easily. That would be another argument for making everything go through LP
in some way.

> Likewise, the Flooder needs to actually have a viable alternative to
> sending bugs to the Flooded. "Viable alternative" is a bit too
> abstract though -- can you help me make it more concrete?

Consider me setting up a daily build on MariaDB. I could point the bugs
at:

   * the Ubuntu package.
   * the MariaDB tracker.
   * the 'launchpad' project on LP.
   * nowhere (blackhole them).
   * a new LP project and triage myself.

Only the first three would have a Flooded. The choice for any of them is
any of the others.

My feeling is that if they aren't wanted on the MariaDB tracker then either
I am doing something like running a daily build of a version with my new
patches applied, or there is no trust between us. In the former case a new
project would allow me to receive bugs on my patches, and forward the rest
myself. In the latter we would be better served by working so that there
was, and the new project could give us space to do that.

Thanks,

James