MOTU Release Charter

[James Westby]

On Thu, 2009-03-19 at 18:16 -0400, Scott Kitterman wrote:
> During the Intrepid cycle the MOTU release team members were asked to come up 
> with a charter for the team.  It's taken us some time to get a draft 
> together, but this:
> 
> https://wiki.ubuntu.com/MOTU/MOTUReleaseCharter

I have some comments on the draft charter. Some are stylistic, and some
are related to the content.

> motu-release members manage each Ubuntu release for those packages
> which belong to the Universe and Multiverse sections of the Ubuntu
> archive, trying to have them in a good shape for the release.
> 
"trying to have them in a good shape for the release" is a rather
limp phrase in my opinion. Surely this statement is the most crucial
of the whole document, as it is the main purpose of the release team.

It currently sounds like it is talking about lots of individual 
packages, rather than a distribution. Having universe in the best
state possible for release should be the aim in my opinion, which
is slightly different to trying to get each individual package in
to its best state.

Also, Universe and Multiverse aren't "sections", they are "components".

> motu-release members coordinate packaging and quality assurance
> efforts for a wide range of packages, working together with interested
> developers to reach targeted goals.

I'm unsure about this point. We don't really have targeted goals for 
MOTU as a whole, except for things like few FTBFS. I also haven't seen
much co-ordination of QA activities from motu-release. Have I missed 
them? If not, what has been stopping this from happening?

Also, aren't QA activities the purview of the QA team? If motu-release
would like to be involved with that then should this be as a liason with
the QA team?

"A wide range of packages" seems out of place, if the intent is to state
that you will co-ordinate QA activities that touch on large numbers of
packages then I believe that should be stated, rather than the ambiguity
implied by that statement.

> motu-release members are a liaison between the MOTU community and
> Ubuntu release managers to coordinate package uploads and new features
> throughout the various stages of the release schedule.
> 
I would say that you co-ordinate the inclusion of new features, rather 
than the features themselves.

> motu-release transitions upload decisions to motu-sru at the time of
> release. In order to meet motu-release goals it may be necessary to
> authorize pre-release SRU uploads. motu-release will hand these over
> to motu-sru and assist with their verification and movement from
> *-proposed to *-updates.
> 
I think the first part should rather be phrased as a grant of a power,
"motu-release is allowed to authorize pre-release SRU uploads where it
allows them to further their work on improving the release. motu-release
will then assist motu-sru with completing the SRU process for these
uploads".

> motu-release or one of their delegates will review all Feature Freeze
> exceptions requested for packages in the Universe or Multiverse
> repositories, which introduce new features or substantial changes
> after FeatureFreeze in order to weigh the potential impact of the
> proposed changes on the rest of the distribution. 
> 
"delegates" hasn't been defined at all, does that need to be in the
charter? If it's just an implementation detail then they shouldn't be
mentioned here either.

Also, is this a power? I can review all feature freeze exceptions if I 
like. The power seems to be in forcing FFes to be requested at all, and
being able to reject them.

It seems like this paragraph should be written as to grant motu-release
the power to request and reject freeze exception requests after a 
certain point. motu-release can then define what point that is and what
requires a request, as you do now.

> Ubuntu developers will not upload a new source package and archive
> administrators will not accept any package uploaded after
> FeatureFreeze without a Feature Freeze exception from motu-release or
> one of it's delegates (having been discussed at the UDS or providing a
> required feature are reasonable arguments for a feature freeze
> exception, but do not remove the need for an exception).
> 
This seems related to the last.

Also, I'm not sure that talking about UDS here is appropriate.

> motu-release will work with Ubuntu developers and contributors in
> order to coordinate efforts to complete library transitions and the
> addition of new packages once a Feature Freeze exception has been
> granted for them.
> 
Is this a power? It seems like a duty to me, unless we have to work
with motu-release, and can't just do it on our own if we like.

"inclusion of new packages" seems better than "addition" to me.

Does motu-release not work with developers to complete library
transitions that start before Feature Freeze? Decoupling it
from the exception would seem to be smart to me.

> motu-release members shall be contacted if the user interface of an
> application needs to change after UserInterfaceFreeze. (this only
> applies to seeded packages). motu-release will facilitate coordination
> with the documenation team. Feature Freeze exceptions for
> UserInterfaceFreeze will not be granted without concurrence from the
> doc team.
> 
Phrasing this as motu-release enforcing freezes on the user interface 
in co-ordination with the doc team would avoid the need to talk about
seeded packages and enshrining your policy on contacting the doc team in
the charter.

> motu-release members can revert intrusive changes that could be
> disruptive to other packages in the distribution if discussions about
> the positive impact are not considered satisfactory by the MOTU
> community. The standard rule about not reverting a reversion applies.
> In the event of a lingering technical dispute, the TechnicalBoard will
> be notified and resolve the issue. 
> 
"The standard rule" is an imprecise phrase to have in a charter.

You later state that this is a power that everyone has, so is there need
to have it in this document?

Also, I'm concerned by the lack of any mention of who cares for these 
packages after being reverted. Given that reverting an upload may lead
to the contributor who did that upload having nothing more to do with
the package it may be left unmaintained for some time, and in an odd
state. Does motu-release feel it should have some responsibility for the
packages that it reverts?

> motu-release members do not have any actual power than is not also
> held by any Ubuntu Developer. All developers are responsible for the
> overall health and well being of the Ubuntu archive. Any developer can
> and should revert unsafe changes to the archive. The authority held by
> motu-release is a delegation from the MOTU based on the
> election/appointment process for motu-release members and the MOTU
> processes approved by MOTU.

If this is going to be in the document, then I don't think it should be
in the "Powers" section. I feel it should be part of an introduction to
the document that expands on these points, and does some of the other
work of defining terms that are used in the document.

Thanks,

James