Creating a PPA requires one to be a team admin

wgrant & I discussed this on IRC. We agreed that while this is indeed a bug, there are policy issues worth considering. As an example, wgrant is a member of ubuntu-bugcontrol, but should definitely not be allowed to create a PPA on it, since that PPA would look as if it had the authority of the whole bugcontrol team behind it.

We also agreed that it would be desirable to implement this without adding more flags and switches.

I can imagine a more abstract "archive collection" concept with a configurable set of people who can create archives in that collection. Perhaps this is too abstronaut.

Why shouldn't wgrant be allowed to create a PPA on ubuntu-bugcontrol ? Its a closed team, its admins will see that the PPA was created, and can take remedial action. Members of the team are trusted to decide whether a bug is important or not, which probably has much more impact on folks impression of Ubuntu than a PPA they would have to choose to interact with.

I suggest making it real simple:
 - open & delegated teams: don't get PPA's
 - all other teams, any member of the team can create a PPA, all admins are notified.

I would think a configurable option per team would be much better for this defaulting to off. I don't think teams like bugcontrol would be appropriate to have any member be able to create PPAs. While we trust various members with private bug information, packaging is a whole different story.

On Mon, Aug 6, 2012 at 10:46 AM, Micah Gersten
<email address hidden> wrote:
> I would think a configurable option per team would be much better for
> this defaulting to off. I don't think teams like bugcontrol would be
> appropriate to have any member be able to create PPAs. While we trust
> various members with private bug information, packaging is a whole
> different story.

And some teams will trust some folk more than others. Thats fine, I
don't think LP has to model this exactly. The key things are that
anyone creating a PPA in a socially privileged context be accountable
for it, and that it be deletable if its inappropriate.

Both of those things are satisfied with what I propose.

Why do I suggest that those things are the key? Because they allow any
abuse to be corrected, in a reasonable timeframe.

If you're worried about social engineering attacks, consider that
anyone can create a plausible looking team name anyway...