Bugs for daily build packages

[Jonathan Lange]

On Tue, Dec 8, 2009 at 4:37 AM, James Westby <jw+debian at jameswestby.net> wrote:
> On Sun Dec 06 22:03:06 +0000 2009 Jonathan Lange wrote:
>> Deryck and I banged out a rough specification here:
>>   https://dev.launchpad.net/DailyBuildBugs
>>
>> I'm keen to hear your thoughts.
>
> 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?

> Would it be too much to have apport always file against LP, and
> then allow an LP project to be configured to auto-push those bugs
> to an external tracker with a plugin? This gives us less coverage,
> but a better experience in terms of getting the information from
> the user and to the desired people.

That, I don't know.

In an ideal world, the Launchpad code base would have an abstract API
for a bug tracker with an implementation for each kind of tracker that
we support, and one of those methods would be 'reportBug'. Well, maybe
that's not the _ideal_ ideal world, but it's my ideal world. I have no
idea how close we are to that.

I don't think it would be a good idea to special case such
auto-pushing just for this.

> It would also lead to gardening
> problems on LP too.
>

Really? Such as?

> 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

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?

jml