MOTU Release Charter

[Scott Kitterman]

On Tue, 24 Mar 2009 16:33:23 +0000 James Westby <jw+debian at jameswestby.net> 
wrote:
>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.
>
Great and sorry for the delayed reply. If this is to be a good charter it 
needs to reflect more than what the current motu-release wants.  It needs 
to describe something that is broadly supported by motu.

>> 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.

Agreed.  I think that better reflects the intent.

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

nod.

>> 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?

This is something we've talked about, but we've been short on actual 
specific ideas for.  

>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?

I guess it depends on what one means by QA.  I don't think that the QA team 
has a lot of focus on Universe.  Speaking for myself, I think of the 
current QA team really being for Main.

>"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.

I think that sounds right.

>> 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.

Agreed.

>> 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".

I like that.

>> 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.

I think they are an implementation detail and we should remove it.

>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.

Agreed.

>> 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.

 Agreed.  It should be approved spec.

>> 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.

Agreed.

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

OK.

>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.

Historically we've only started work as a team after feature freeze.  It 
has been both for new transitions and finishing ones started before FF, so 
this should be clarified.

>> 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.

Agreed.  The seeded packages discussion belongs in the user interface 
freeze definition, not here.
>
>> 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.

True and AFAIK it's a matter of tradition, not documented, so I don't know 
how best to deal with it.

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

Since it was a reversion that caused MC to request this document be 
created, I think we have to deal with it.

>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?

I think so.  We have some traditional approaches about who-touched-it-last 
that I think apply.  I did care more for ruby-gems than I otherwise would 
have (even though it wasn't me that uploaded the actual reversion).

>> 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.

That makes sense.

Thanks for your comments,

Scott K