Not logged in - Log In / Register

Blueprint keeps track of who's planning what, who's working on what, who's supposed to sign off on what, and who's supposed to review what. It also allows projects to exercise control over the planning and prioritisation of features so that the community can know exactly which piece is most likely to benefit from their support and contributions.

Specification Roles

Each specification keeps track of the following people:

Project Drivers

Blueprint also keeps track of the people in the project who have the responsibility for setting priorities and release goals. We call these people the "drivers" since they determine the major direction and pace of feature development. The same group are responsible for determining the importance of specific bugs to a major release, they essentially say what needs to get done before a major new series or distribution release can be called "done".

Now, in Launchpad, a project (upstream or distribution) has a very specific structure. And you can specify drivers that have responsibility for the whole project or just for parts of it. This tree illustrates the basic structure of a typical upstream or distro project:

Note that for upstreams, the "project" is optional. Launchpad keeps track of upstreams as products, which can be libraries or applications. If you want to group those together into projects, then thats great, but often products are "standalone".

Each of these parts of the project structure can have a driver associated with them. But specifications in Blueprint can only be targeted to a Product Series ("firefox 1.5") or a Distro Release ("dapper"). We'll explain what that means below. For the moment, the important thing is to know that when you are looking at the "firefox 1.5" series you might see that it has up to three drivers - one from the series, one from the product, and possibly even one from the project.

This allows a project to appoint someone who has "driver" responsibility in ANY series in ANY product in the overall project. For example, that person could be the most senior architect or development team, with the ability to determine the priorities of any library or app in the project. For example, in the case of the Mozilla project, that would mean that they could approve a bug for fixing or a feature for implementation in any major release of Firefox, Thunderbird, Gecko, Necko or Sunbird.

At a lower level, you might have a person or team who have "driver" responsibility for a single product - they could approve features for any series in that product, like 1.5 or 2.0. And of course, you can appoint a team or person to be the driver of a single series. Those people will only have permission to target a spec to that series, not to any other series in the project unless they are explicitly given that permission too.

So this allows upstreams to control who is in the drivers seat for any particular major line of development.

Similarly, for distributions, you can have an overall driver at the distribution level, and then separately you can add specific drivers for specific releases. Now, this is useful because drivers will also be able to approve a bug fix for backporting to an existing release. That means that might you want to have a larger team that is "driving" the NEXT release, and then a much smaller backporting team that is responsible for approving the backporting of fixes to bugs in older stable but still-supported releases.

In both upstreams and distributions, the "drivers" for a series or release is the set of drivers from the tree above that series or release. So for upstream, if you have set a driver on the series, the product, and the product is part of a project with a driver, then you would have three drivers who can approve specs for that series.

Unspecified Driver

You do not HAVE to specify a driver. In general, Launchpad will recognise the driver(s) you tell it is (are) responsible for a product, project or series. If NO drivers have been set, anywhere in the "tree", then it will use the registrant of the top-most object in the tree as the driver. In the case of distributions thats simple - its just the registrant of the distribution. In the case of an upstream series, though, it depends on whether or not the product is part of a project. If it is, then the project registrant becomes the driver for every series in the project. If there is no project then the product registrant is the driver for every series in the product.

This may sound complex, but it basically means that after you create a product and/or project, you can create series and start targeting specs to those series. You will automatically be the driver on all of the series in your product if you registered your product. The permissions will "just work". Nobody else will be able to approve specs to series unless you specifically empower them to do that, by making them a driver or making them part of a team that is a driver.

BlueprintRoles (last edited 2008-06-17 14:21:16 by localhost)