MOTU Release Charter
dktrkranz at ubuntu.com
Wed Mar 25 09:11:20 GMT 2009
-----BEGIN PGP SIGNED MESSAGE-----
Thanks for your feedbacks James!
James Westby ha scritto:
>> 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.
Looks reasonable to me.
> Also, Universe and Multiverse aren't "sections", they are "components".
dak call them "sections", does Ubuntu archive use a different naming?
>> 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?
There are several: FTBFS, NBS, transitions, and so on. Probably they are
not "plain QA" but more about "archive consistency". We followed several
transitions in the past, trying to get them finished in a reasonable
time, do you think we should document better their status? (something
like "Bits from motu-release" emails, like Debian teams do).
>> 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
>> 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 so. We assign some packages which belong to a given domain
(GNOME, KDE, Mozilla, and so on) to a delegate who has great knowledge
of packaging policies and infrastructure. We ask them to accept the role
and then send out a email to announce them. They contribute to the
motu-release team, so this should be documented.
> 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.
It's not about power, but responsibility. I think we have not the
"power" to block anything, but we give advice on what could be fine from
a safe release POV.
>> 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.
Some people don't consider a NEW package as a feature, stating so we
state it clearly.
> Also, I'm not sure that talking about UDS here is appropriate.
Why not? Suppose I had a talk at UDS about a given feature, it is
considered important and accepted for the release. I expect it could
enter without much trouble (according to release schedule timings).
>> 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.
See above: s/powers/responsibilities/
> "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.
Transitions could be painful, and they could require new packages and
complex tasks which require co-ordination.
>> 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.
That way we could be contacted for UI changes related to non-seeded
packages, which do not fall into UI Freeze.
>> 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?
Reverting a change means be aware of the change made, its disruptive
potential and benefit the reversion apports to the release. I suppose
spotting the disruptive change, discussing it on IRC/ML/whatever and
taking responsibility in reverting it is a good demonstration of care.
>> 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.
. ''`. Luca Falavigna
: :' : Ubuntu MOTU Developer
`. `'` Debian Maintainer
`- GPG Key: 0x86BC2A50
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Motu-council