Distribution drivers permissions may need redesign

Ubuntu is an exception from all other launchpad projects and distros. They have week drivers and powerful release managers. I would prefer to have one set of rules for drivers and release managers:

Ubuntu release managers team is a small team people who are delgated the authority to complete a release. The have full edit control over the series and milestones (no admins needed). They can target bugs to milestones and assign them to developers (no bug supervisor needed)
    - Approve(?) bug nominations
    - Approve blueprints
    - Edit all aspects of a specification
    - Accept blueprints for sprints
    - Control the agenda of a sprint
    - Can view and edit announcements before they are public
    - Can create series and milestones

Drivers are a larger team of helpers who work under the direction of the release manager. They nominate bugs (not users)
    - Nominate a bug
    - Set package bug guidelines
    - Set official bug tags
    - Remove package bug subscriptions on behalf of others
    - target bugs to milestones and assgin them (release managers to un do this)

Curtis, the role of "drivers" as currently implemented is the same as
your description of release managers: deciding which issues and features
matter for a particular series / release / milestone.

The general model is that "anybody can propose an issue as RC but only
drivers can confirm the issue as being RC". Ubuntu, being a very large
project, needs a more sophisticated model. But I haven't yet seen a
comprehensive review of how we can structure things so that Ubuntu is
not special cased, but has merely configured the general system in the
way that suits them.

Some of the items in your list of "RM" capabilities look more like
project admin capabilities to me. Ubuntu should just have the RM team
have admin rights if that's what they want.

What's needed now is a more detailed review of the workflows associated
with release management, and the design of a permissions system which is
natural "out of the box" for a typical small project, but which can be
configured to handle a large and sophisticated project, too.

By "natural out of the box" I mean that the person who registers a
project initially can "just do anything", but that over time, as the
project becomes larger and richer, they can delegate responsibilities
and permissions effectively.

For example:

 - should the set of people who can propose bugs / specs to a series be
restricted?
 - should there be controls on which people can set which bug / spec states

In the case of a small project (the default out-of-the-box experience
for a new project) the answer is no, but for a large project like Ubuntu
the answer is yes. Don't special case Ubuntu, use this opportunity to
build a clean, general approach which works in the small case and can be
made to work for Ubuntu too.

Mark

The ubuntu-drivers team is currently filing two Launchpad roles for Ubuntu - the Maintainer and the Driver for Ubuntu and the permissions listed in the description may come from either of those roles. Another role that Ubuntu is not using is the "Release Manager" role for a series - https://launchpad.net/ubuntu/maverick has no release manager set.

I think the permissions / tasks should be examined to determine which roles can perform them and then if necessary the permissions should be moved to a different role. For example, I believe the bug supervisor role, if a bug supervisor is set, should be able to set package bug guidelines and official bug tags.

The following information was sent to the Ubuntu Technical Board mailing list as I thought a discussion regarding who should be allowed to perform certain activities was more of a social discussion.

"I've done some research into the permissions associated with the ubuntu-drivers team in Launchpad and have some ideas about how the permissions for performing actions should be redistributed. Before moving forward I wanted to ensure that this seems reasonable.

Some background information. We currently have the ubuntu-drivers team fulfilling two roles in Launchpad for Ubuntu - both the distribution maintainer and the driver. Some other roles that we have available for assigning permission include the distribution bug supervisor (ubuntu-bugcontrol effectively) and the release manager for a series. At this point in time we don't seem to be using the release manager as one is not currently set for Maverick. Perhaps the ubuntu-release team is good fit for this particular role.

I think the ability to perform specific actions should be distributed to the following teams:

set package bug guidelines - bug supervisor (ubuntu-bugcontrol)
set package bug acknowledgements - bug supervisor (ubuntu-bugcontrol)
set official bug tags - bug supervisor (ubuntu-bugcontrol)
    This may result in a large number of official bug tags so they should be
monitored.

approve bug nominations - release manager
target bugs to a milestone - release manager
    This is currently assigned to bug control which hasn't been an issue but
should be fixed as long is doesn't exclude uploaders.

approve blueprints - distribution driver (ubuntu-drivers)
edit all of a specification - distribution driver (ubuntu-drivers)
control agenda for a sprint - distribution driver (ubuntu-drivers)

An additional target of opportunity might be restricting it so that only the
bug supervisor can nominate bugs for a release so that the release managers
have a smaller subset of nominations to review."

On Fri, 2010-10-01 at 15:38 +0000, Brian Murray wrote:
> I think the ability to perform specific actions should be distributed to
> the following teams:
...
> approve bug nominations - release manager
> target bugs to a milestone - release manager
> This is currently assigned to bug control which hasn't been an issue but

There is an open bug about this the RM targeting bugs to a milestone.
There is also a bug that implies it was fixed.

> approve blueprints - distribution driver (ubuntu-drivers)
...
> control agenda for a sprint - distribution driver (ubuntu-drivers)

I would have assumed the RMs control the agenda of a sprint since they
are responsible for planning what will be included and when it must be
delivered.

On Fri, Oct 01, 2010 at 04:00:06PM -0000, Curtis Hovey wrote:
> On Fri, 2010-10-01 at 15:38 +0000, Brian Murray wrote:
> > approve blueprints - distribution driver (ubuntu-drivers)
> ...
> > control agenda for a sprint - distribution driver (ubuntu-drivers)
>
> I would have assumed the RMs control the agenda of a sprint since they
> are responsible for planning what will be included and when it must be
> delivered.

In Ubuntu, different groups are responsible for blueprint-level planning
(we treat this more or less as a management function) vs. bug
nominations etc. (we treat this as an operational function).

We had to ask Tom Haddon to change the status of natty & lucid today. Although Tom was prompt and helpful as ever, it's yet another hand off in the new release cycle process, and it's probably not a great use of his time either.

Bug 654795, which is Fix Committed, is about allowing the bug supervisor to set the bug reporting guidelines and acknowledgement.

On Fri, Oct 01, 2010 at 04:00:06PM -0000, Curtis Hovey wrote:
> On Fri, 2010-10-01 at 15:38 +0000, Brian Murray wrote:
> > I think the ability to perform specific actions should be distributed to
> > the following teams:
> ...
> > approve bug nominations - release manager
> > target bugs to a milestone - release manager
> > This is currently assigned to bug control which hasn't been an issue but
>
> There is an open bug about this the RM targeting bugs to a milestone.
> There is also a bug that implies it was fixed.

I believe the bug to which you are referring is bug 496696. Testing
this on both launchpad.dev and staging.launchpad.net I was unable to
recreate the bug though so I agree that it seems fixed.

What this means is that a series release manager currently can approve
bug nominations, target them to a series, and target bugs to a
milestone.

--
Brian Murray

Of the things to do outlined in comment 4 the following has been accomplished:

set package bug guidelines - bug supervisor (ubuntu-bugcontrol) - DONE
set package bug acknowledgements - bug supervisor (ubuntu-bugcontrol) - DONE
set official bug tags - bug supervisor (ubuntu-bugcontrol) - DONE

approve bug nominations - series release manager - DONE (no change required)
target bugs to a milestone - series release manager - DONE (no change required)

I've additionally resolved Launchpad bug 114766 which requested that only the bug supervisor should be able to nominate bugs for a release. This will make bug nominations an additional way to bring relevant and important bug reports to the release team's attention.

The only further change, in my opinion, is to expand the "Release manager" role for Natty (and other releases) to a team so that we can then remove people who only need to manage nominations and milestones from the ubuntu-drivers team.

On Thu, Nov 4, 2010 at 10:07 AM, Brian Murray <email address hidden> wrote:
> The only further change, in my opinion, is to expand the "Release
> manager" role for Natty (and other releases) to a team so that we can
> then remove people who only need to manage nominations and milestones
> from the ubuntu-drivers team.

Thats easy done without a code change.

On Thu, 2010-11-04 at 00:55 +0000, Robert Collins wrote:
> > The only further change, in my opinion, is to expand the "Release
> > manager" role for Natty (and other releases) to a team so that we
> can
> > then remove people who only need to manage nominations and
> milestones
> > from the ubuntu-drivers team.
>
> Thats easy done without a code change.

Not quite, the immediate driver of a series get elevated permissions to
create and manage milestones except for Ubuntu. We need to remove the
exception so that the release manager has the same powers to match their
responsibilities.

I believe Ubuntu still want the exception that block drivers from
creating series.

--
__Curtis C. Hovey_________
http://launchpad.net/

On Thu, Nov 04, 2010 at 02:13:27AM -0000, Curtis Hovey wrote:
> I believe Ubuntu still want the exception that block drivers from
> creating series.

I'm not sure we do. It would be convenient not to have to ask IS for
this every time we're initialising a new series, when IS is already
heavily loaded with handling the release that just happened.

As far as I'm aware, the reason that that exception was added was not
because we asked for it (in fact, I didn't even realise it was
Ubuntu-specific - I suppose I thought it was for distributions in
general), but because creating a series in Ubuntu which wasn't published
yet used to break all sorts of bits of Launchpad in amusing ways. My
understanding is that that breakage has now been fixed.

On Thu, 2010-11-04 at 11:35 +0000, Colin Watson wrote:
> On Thu, Nov 04, 2010 at 02:13:27AM -0000, Curtis Hovey wrote:
> > I believe Ubuntu still want the exception that block drivers from
> > creating series.
>
> I'm not sure we do. It would be convenient not to have to ask IS for
> this every time we're initialising a new series, when IS is already
> heavily loaded with handling the release that just happened.
>
> As far as I'm aware, the reason that that exception was added was not
> because we asked for it (in fact, I didn't even realise it was
> Ubuntu-specific - I suppose I thought it was for distributions in
> general), but because creating a series in Ubuntu which wasn't published
> yet used to break all sorts of bits of Launchpad in amusing ways. My
> understanding is that that breakage has now been fixed.

This is great news. To be clear, are all 45 members permitted to create
a series?

Can a driver create an experimental series? I suspect the answer is
*yes*, but drivers will not because Ubuntu does not use them.

--
__Curtis C. Hovey_________
http://launchpad.net/

On Thu, Nov 04, 2010 at 12:54:28PM -0000, Curtis Hovey wrote:
> This is great news. To be clear, are all 45 members permitted to create
> a series?

I would not want the entire current drivers team to have this
permission, no, but we were talking about reducing it anyway, weren't
we? Many folks are in that team in order to be able to manage bug
nominations, notably canonical-qa with its 13 members.

Ideally, the team with this permission would be ubuntu-release, but it
would be acceptable for it to be that subset of the current
ubuntu-drivers team who are responsible for feature planning (i.e.
managers, tech leads, and the TB). Removing uds-organizers from
ubuntu-drivers might be difficult, though, and there are a lot of people
in that who aren't normally involved in the task of creating a new
release.

I notice that we currently have ubuntu-drivers in both the Maintainer
and Driver slots. Could you clarify the precise difference between
those? Perhaps ubuntu-release could occupy one of them.

> Can a driver create an experimental series? I suspect the answer is
> *yes*, but drivers will not because Ubuntu does not use them.

I've never had occasion to look into this, and as you say we don't use
them so it doesn't really concern me.

On Thu, 2010-11-04 at 13:29 +0000, Colin Watson wrote:
> > This is great news. To be clear, are all 45 members permitted to
> create
> > a series?
>
> I would not want the entire current drivers team to have this
> permission, no, but we were talking about reducing it anyway, weren't
> we? Many folks are in that team in order to be able to manage bug
> nominations, notably canonical-qa with its 13 members.
>
> Ideally, the team with this permission would be ubuntu-release, but it
> would be acceptable for it to be that subset of the current
> ubuntu-drivers team who are responsible for feature planning (i.e.
> managers, tech leads, and the TB). Removing uds-organizers from
> ubuntu-drivers might be difficult, though, and there are a lot of
> people
> in that who aren't normally involved in the task of creating a new
> release.
>
> I notice that we currently have ubuntu-drivers in both the Maintainer
> and Driver slots. Could you clarify the precise difference between
> those? Perhaps ubuntu-release could occupy one of them.

Ubuntu has an odd story. Owners can change everything in a project,
drivers can change items related to planning. The driver of a series is
a release manager can has extra power to create, edit, and delete
milestones. Since We do not want dozens of people to have the power to
change the Ubuntu page, or edit every series and milestone in Ubuntu,
Ubuntu owners have very little power to make changes.

Other distro owners can change their distro page and manage series and
milestones without the assistance of an admin. The driver of another
distro is like the driver of a project--change work items.

I want a single set of rules for all projects and distros:
owner can see and change everything.
release managers set goals for a series (super drivers)
drivers are trusted to update project items to meet goal
bug supervisors are like drivers, but have extra bug permissions.

The release manager role can be the owner, but project often run
concurrent series and the owner often delegates to a smaller group to
meet each series' goals.

In the next few months owner and drivers will be permitted to see all
private bugs and branches for their distro/project. They will not need
to be subscribed to individual bugs and branches, they do not need to be
members of the bug supervisor team.

--
__Curtis C. Hovey_________
http://launchpad.net/

I'm a bit unclear on what remains to be done. According to comment #10 and comment #4, I think we need to:

- Create a new team to fill the 'release manager' role, and populate it appropriately (if we don't already have one)
- Set the release manager of each supported release to this team
- Review ubuntu-drivers membership and limit it to people who need to manage blueprints

What else? Currently, ubuntu-drivers fills the "maintainer" role for Ubuntu, not just the "drivers" role. What permissions are associated with the distro maintainer?

I agree about the next steps for this.

I've found a couple of things that the distribution maintainer (owner) can do:

class AdminDistributionMirrorByDistroOwnerOrMirrorAdminsOrAdmins
class EditDistributionMirrorByOwnerOrDistroOwnerOrMirrorAdminsOrAdmins
class EditSpecificationByTargetOwnerOrOwnersOrAdmins
class AdminSpecification
class EditSpecificationSubscription
class ViewAnnouncement
  unpublished ones
class EditAnnouncement

class NominateBugForDistroSeries
  (along with bug supervisor)
class EditDistributionSourcePackageByDistroOwnersOrAdmins
  (along with bug supervisor)
class EditDistroSeriesByOwnersOrDistroOwnersOrAdmins
  (along with the distro series owner)

I found these by grep'ing for "user.isOwner(self.obj.distribution)", "user.inTeam(self.obj.distribution.owner)" and "user.isOneOfDrivers" so I think that covers it.

I've started to compile a list of permissions: https://wiki.ubuntu.com/LaunchpadPermissions

Further progress is blocked on bug 703002, which needs to be fixed so that we can remove the Canonical QA team from ubuntu-drivers

The other blocker is bug 451390. We currently set the Series RM to ubuntu-core-dev to work around this. Once we have that bug fixed, we can set the Series RM to ~ubuntu-release (as it should be conceptually).

Ignore comment #20, I was mistaken.

Martin, that workaround shouldn't be necessary. ~ubuntu-core-dev has upload rights to all components, so it can already approve nominations regardless of whether it is series RM or not. Bug #451390 is limited to packageset- and package-based permissions.

I have now changed the driver for all stable releases to ubuntu-release, and verified that this does not regress the ability of a core-dev to target tasks to a stable release.

I have added canonical-qa to ubuntu-release, although that requires confirmation from an administrator of that team (I've given Pete Graner a heads-up and summary on IRC).

After that, I think the next step is to remove canonical-qa from ubuntu-drivers.

Pete has approved canonical-qa's membership of ubuntu-release, so I have gone ahead and removed canonical-qa from ubuntu-drivers.

From question https://answers.launchpad.net/launchpad/+question/168164

The daterelease field is not directly setable. It is implicitly set in the when the series status is set to CURRENT using the web UI. Registry Administrators can change the field using an API script...

...There have been many team changes made since then and I think we can consider changing distroseries to permit series drivers (RMs) to change all these fields: version name status nominatedarchindep changeslist datereleased

Ubuntu is owned by 42 people (~ubuntu-drivers) The series are owned by 22 people (~ubuntu-release) These teams are largely the same except for ~canonical-qa who are members of ~ubuntu-release.

The composition of canonical-qa team has changed, and some of the defect analysts who had permissions to nominate to series (necessary by job), couldn't. Some of the security team members need to do this, as will some of the support team as well, so the lack of permissions to permit series drivers as a separate task is causing issues.

A launchpad team was set up ubuntu-release-nominators to contain those individuals who need to do these nominations, and they've been made part of ubuntu-release (instead of canonical-qa). These individuals don't need all the permissions that ~ubuntu-release has, and being able to make release series nominations should be separated out and people be assigned to do that task explicitly.

What is currenly needed to close this bug?

I am not certain what needs to change. Reading back a few comments, I think the issue is that Ubuntu wants a group other than drivers to approve bug nominations.

We recently revised bug editing permissions to ensure maintainers and drivers can do anything that a bug supervisor can do -- full editing of bugs. Supervisors can nominate a bug to be fixed a series, driver an maintainer can directly target it (no need to nominate.)

If this issue is about allowing the security people to make a bug nomination, then the team should become a member of ubuntu-bugs. In a few weeks (with the advent of Sharing) bug supervisors will not be forced to get email. Users can use structural subscription to get the mail they want. That means any person in an Lp distro/project role can subscribe to get bugs, and they will be notified of Embargoed Security bugs if they the project also shares Embargoed Security Information with the person/team.

If Ubuntu asking for a new role that allows someone to approve bugs can approve bug nominations, but cannot edit bugs like the other three roles (that sounds silly), nor can they manage the release, then the database needs to store that information. We will also need to update the permissions again to support the role.

Sorting out the ubuntu-drivers team was the original purpose of this bug, and that's now pretty much dealt with: that team is responsible for blueprint planning, and the other functions have been broken out.

However, as outlined in comment 27, we have a regression of sorts as a result of this work, because part of the problem was just moved elsewhere: the ubuntu-release team is now an amalgam of multiple largely-unrelated privileges, and we need to sort that out. I've clarified with Kate that what she meant was the ability to *target* to a series (== the ability to approve nominations), not the ability to make a nomination.

The options for how to acquire the ability to approve nominations are:

 * be a driver/maintainer of any of the bug targets
 * have upload access to any of the source package bug targets

In this case, neither is really appropriate. Being a driver/maintainer of either Ubuntu or one of the Ubuntu series grants quite a few permissions, and many of the people in question don't and shouldn't have upload access.

I think the thing that isn't represented well here is that we have multiple levels of QA. Access to the bug supervisor role is necessary for all kinds of QA work, such as setting bug task statuses to Triaged. Some of these are relatively junior tasks that we distribute to essentially anyone who asks and who testifies that they've understood the basics. But the ability to approve bug nominations is a senior QA task, because it involves the ability to add things to the queue to be fixed for a release, which is a queue we want to keep well under control so it should only be manipulated by people working with the development teams.

In the past, we lumped this in with the release manager role, and there is some sense to that: that's why having ~ubuntu-release-nominators as a member of ~ubuntu-release was a better compromise than the previous situation. But "Release manager" in the Launchpad UI actually means the series driver, so we've only gained a limited amount here: we've moved senior QA people from the distribution driver to all the series drivers, which has reduced privilege a bit, but not massively.

We've gone back and forward trying to use the existing available slots for this, and I don't think any of them have been quite right. Loath though I am to suggest it because I know it's more work, I think what we really need here is a new slot for people who are allowed to accept bug nominations to a distroseries, sort of a "bug drivers" role, and acknowledge that full drivership for something the size of a distribution involves a good deal more than that with broader skills.

Are QA people abusing that power?

There is a growing need to add others, who by nature of their job have to target bugs to releases (support engineering group), and the lack of access impedes their productivity. However, some of that team and others will not have as much background as the current members of ~ubuntu-release-nominators, so chance of inadvertent errors is greater. Restricting the scope of impact to just the "bug driver" role, would remove a fair amount of risk.

Are they all-and-sundry, or trusted-but-naive? What is the impact of
the mistakes they would be able to make today? How long would it take
to fix each such mistake, and how many do you think such an individual
would make before they are no more likely to make a mistake than, say,
you?

To be honest, I'm mostly out of energy for this bug. We seem to have got things to a basically acceptable state and I'm very tempted to just close this out. The people who have fairly widespread bug-nomination-approval privileges as a result of this bug and for whom those privileges are at all disputed are people whose jobs involve working with bugs all the time; I think it's reasonable to expect that such people would learn the ropes pretty quickly or else move on.

The alternative is to create a fairly substantial new edifice to divide up the privileges further; and I think there's an argument that we are reaching the point of diminishing returns here. The LP security structure is pretty complicated already. Kate, would you be willing to go along with this?

The one point where this is genuinely awkward is that I'd like to grant ubuntu-release the ability to approve uploads to the development series as soon as my patch for per-pocket queue admin permissions is deployed; and *that* is too broad a permission to be granted to people who don't need it, as it's potentially quite disruptive if misused, even innocently. However, we could deal with this by a small team restructuring. Instead of ubuntu-release consisting of individual release team members directly plus ubuntu-release-nominators which contains various extra QA people, we could invert this: make ubuntu-release a member of ubuntu-release-nominators, and make ubuntu-release-nominators the driver for each Ubuntu series. It would then be straightforward to grant extra queue admin permissions to ubuntu-release.

Agreed, this bug seems well past its expiration date, and the situation seems more under control. A new bug would be appropriate if there are specific further improvements needed.