Re: [Xen-devel] [DOCDAY] Maintenance Release Policy

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-11-27 at 09:56 +0000, Lars Kurth wrote:
> > (I think s/4.3/3.4/ was intended in the above)
> Yes, it was me and this indeed a typo
> 
> Defining what we do is actually what I was looking for, as this is not clear 
> to everybody.
> 
> > Each stable branch has a maintainer who is nominated/volunteers and is
> > accepted via consensus among the maintainers and committers (XXX or just
> > committers?). 
> I am wondering whether we should treat this exactly like maintainership. It's 
> the same idea.
> We could just add a "stable release" section to the MAINTAINERS file and 
> follow the same 
> process of nominating a maintainer. Or track the stable release maintainer in 
> the branched
> versions of the file. Does anybody have any views?

Lets do it in the stable branch version for now with a reference. I'll
send out some patches.

> Maybe a short section of what the responsibilities of a release
> maintainer would be useful (view a view to making it a little easier for 
> somebody to
> step up should they wish to) and a little section on what to do if a 
> contributor feels that
> a bug-fix should be backported (with a view to making the release maintainers 
> life
> easier). Anyway, this is just a suggestion.
> 
> Otherwise this sounds like a good proposal and starting point. Thanks
> for putting it together.

No problem.

Final draft is below, incorporating your suggestions (which has meant
substantial changes to a few paragraphs). I'm shortly going to be adding
it to http://wiki.xen.org/wiki/Xen_Maintenance_Releases and fix up the
formatting / links etc.

Ian.

8<-------------------------------------

= Stable Maintenance Branches =

Each new Xen release X.Y.0 starts a new stable maintenance branch.

Each such branch is in its own mercurial repository
xen-X.Y-testing.hg. See [[Xen Repositories]] for more information
about the current branches.

Releases are intended to happen roughly every 3 months. The first
release on a stable branch is often sooner and as the branch reaches
the end of its life the interval may be longer.

In general Xen.org supports the two most recent stable branches at any
given time. When a new X.Y.0 release is made there is usually one more
release on the to-be-retired stable branch to mop up any loose patches
sitting in the repository at which point the branch is retired. For
example we are currently in the 4.3 development cycle and are
supporting two stable branches: 4.1-testing and 4.2-testing. After
4.2.0 was released there was one more release in the 4.0-testing
stream (4.0.4) and then the 4.0 branch was retired.

= Stable Branch Maintainer =

Each stable branch has a maintainer who is nominated/volunteers
according to the "Maintainer Election" process described in the
[http://www.xen.org/projects/governance.html project governance],
resulting in the patching the MAINTAINERS file in the relevant branch.

For the branches maintained by Xen.org one of the regular xen-unstable
committers or maintainers would usually step up as maintainer. However
other community members can also step up to maintain a stable release,
typically once Xen.org no longer does so.

The stable branch maintainer is responsible for identifying suitable
candidates for inclusion in the stable branch both according to their
own judgment and by evaluating requests from the community (see
below).

= Stable Branch Patch Inclusion Policy =

No new development happens in the X.Y-testing branches, instead
changesets are backported from xen-unstable. Where this is not possible
(perhaps unstable has moved on such that the patch cannot be applied or
the approach used in unstable is otherwise not valid for the stable
branch) then a specific fix can be created for the stable branch.
However it is a requirement that the issue will always be fixed in
unstable first (this is to avoid regressions on the next major
release).

In general only bug fixes are accepted into stable branches and new
features are not normally accepted. (There can be exceptions, e.g. it
was agreed that 4.2.1 would take a more relaxed approach to features
which improved xl compatibility with xm). As time passes each stable
branch becomes more conservative and the barrier to accepting a patch
for backport becomes higher.

Changesets are included in the stable branch at the discretion of the
branch maintainer.

= Requesting A Backport =

As well as changesets identified by the branch maintainer as being suitable
for backport changes can also be nominated for inclusion in the stable
branch by making a request to the stable maintainer on xen-devel
either by noting it as such in the submission of the original patch to
xen-unstable or by a subsequent explicit email to xen-devel. Such
requests should be copied to the relevant stable maintainer. In
addition as part of the the stable release process the stable
maintainer will send one or more requests to xen-devel soliciting
suggestions for patches which should be included.




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel