MOTU Release Charter

[James Westby]

On Wed, 2009-03-25 at 10:11 +0100, Luca Falavigna wrote:
> > Also, Universe and Multiverse aren't "sections", they are "components".
> 
> dak call them "sections", does Ubuntu archive use a different naming?

Sections are "x11", "python", etc.

  http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections

Debian policy calls "main", "contrib" and "non-free" "areas", but I 
thought we called universe etc. "components".

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

I think more communication would be good, yes. Aside from that if the 
activities you refer to are about archive consistency, then perhaps it
is better to talk about that in the charter?

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

OK, so I think delegates should be defined elsewhere, and their role 
given there, rather than including it in this paragraph.

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

This seems odd to me. This paragraph was placed in the "Powers" section,
and I do see it as a sort of power. While I could request that everyone
contact me before uploading everything, I don't think it would actually
happen.

If you feel that it is a responsibility then move the paragraph in to 
that section.

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

OK.

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

It seems to me that your policy on accepting or not a given request
shouldn't be documented in the charter, unless it is crucial to the
functioning of motu-release.

This occurs at a few points in the document. If you would like to
record things such as what factors you consider important in freeze
exception requests then do so, but I don't think the charter is the
right place for that.

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

Yes, but your phrasing states that you will only supervise transitions
that you granted exceptions for. I would expect a release to work to
complete outstanding transition regardless of whether they authorized
them (at least where they weren't started regardless of the rejection
of a freeze exception). I assume it is just a wording problem, but if so
it is important to fix it.

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

That to me seems to be part of the definition of the UI freeze, which
is defined elsewhere. I would advise against including things like this
in the charter, or it will mean that we have to re-write the 
motu-release charter every time we want to change an aspect of the 
freeze. What happens if we change the list of packages that are 
restricted by UI freeze to include some that aren't seeded? What
happens if we split UserInterfaceFreeze in to two parts?

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

Yes, but I was talking about caring for the package after it has been
reverted. Your example only goes as far as the revert. What happens if
the reverted package doesn't work? What happens when the archive opens
again? Reverting a package isn't always going to be trivial to undo,
and isn't without its risks.

Thanks,

James