policy for membership in MOTU key teams

Emmet Hikory persia at ubuntu.com
Wed Jul 2 14:50:51 BST 2008

Stephan Hermann wrote:
> Stefan Potyra wrote:
>> as evolved by the discussion for motu-sru members, I guess it might
>> make sense to have a good general policy.
> I would like to see a policy for:
> motu-sru / motu-release:
>        * Changing Members every release cycle
> Why? It would be a good practice for newer MOTUs to step up and learn
> the "hard release work".

    I believe there are certain sorts of expertise and interest that
drive people to become part of this team, and that we would do well to
foster that, and encourage repeat activities.  That said, if there is
a sufficiency of interest in a rotation, I'd rather create teams to
handle a specific release for the lifecycle of that release (typically
2 years), rather than change membership of the same team each release.

    To expand on this, each team would be selected during the
toolchain wait for a release, based on their individual documented
plans for the release and familiarity with release planning processes.
 This team would then be responsible for ensuring the quality of the
release: focusing on selecting transitions to pull from Debian,
upstream updates for local packages, general integration, archive
consistency, low bug count, etc.  As the release nears, this team
would have a larger and larger role in ensuring that critical issues
are resolved and the chances of regression are reduced.  Once the
release happens, this team would coordinate SRUs for the release and
generally watch after the release as is ages.  After the following
release (about 1 year after selection), the workload is then further
reduced, as the release fades into senescence, and after the releae
becomes unsupported, the role has expired.  This process allows for
reasonably long terms, opportunities for fresh ideas and fresh energy,
and reduces handover confusion between the release team and the
updates team.  Further, the experience of working with the various
freezes will help build expertise in the team in code review, likely
improving their ability to do SRU work.  Lastly, by having individuals
responsible for a single release, the chances that those people have
that release running and available for testing are very much

    Despite the attractiveness of such a solution, I believe that the
various stages of release planning require very different
personalities, and that we would do well to foster the development of
expertise at the given role in those of us who have those
personalities, rather than encouraging lots of turnover or expecting
people to fufill multiple roles (although some may also be good at
this).  I see three key portions of release management, as follows:

1: Definition of target goals for release
2: Monitoring and coordination to meet freeze requirements
3: Regression potential analysis for release updates

    In the first portion, we would do well to have people who are
familiar with upstream plans, have a good understanding of upcoming
transitions planned for Debian, and keep track of plans by various
Ubuntu teams.  These individuals would be in the best shape to help
determine what goals can be achieved, and what coordination between
groups is needed to avoid conflict and confusion.  I would expect this
coordination and review to happen early in the cycle, and be
essentially static by Feature Freeze (as we're not likely to be making
many significant changes after FeatureFreeze, unless we've done a poor
job of coordination).

    In the second portion, we would do well to have people who are
good at regression analysis and testing, and who understand how any
given set of changes is likely to impact other aspects of the release.
 Rather than being communicators and coordinators, these people are
more reviewers and controllers, and have secondary focii on archive
consistency, verification that everything works (to some acceptable
minimum level), and oversight of integration testing of any last-minut
updates.  I would expect this work to start around FeatureFreeze, and
last through to the final release (at least for packages not included
on any pre-built images).

    In the third portion, we would do well to have people who are good
at code review in many languages, have good relationships with the
various QA teams, and a strong understanding of common issues related
to handling updates for stable releases (given that many of the
assumptions that may be safe in a development release do not apply for
stable release updates).  While these people are also reviewers and
controllers, this role is much more about understanding the specific
change, the entirely of the implications of making such a change, and
striving for minimal visibilty to users beyond targeted solutions to
known problems (be they user-reported bugs or otherwise), which
strikes me as different than the sort of review done pre-release.  I
would expect this work to start around FinalFreeze, with the team
familiarising themselves with the changes for the new release, and
continue for the remainder of the lifecycle of the release.

    If these teams do require the different skillsets and mindsets
described above, there is significant value in preserving the
expertise through several cycles (an argument against turnover),
clearly segmenting the teams and their roles (an argument against
merging the teams), and replacing team members through a process more
closely related to apprenticeship than any sort of election (assuming
that MOTU provides general oversight to avoid excessive insularity).


More information about the Ubuntu-motu mailing list