[Xen-devel] [DOCDAY] Maintenance Release Policy

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

Lars (I presume it was he who added this TODO) would like to have a
policy written down.
http://wiki.xen.org/wiki/Xen_Document_Days/TODO#Document_Policy_on_Maintenance_Releases
 says:
        Which releases are supported, for how long. Owners. As well as a
        mechanism for individuals (or vendors) to take ownership of
        older releases (as is the case for Xen 4.3). 

(I think s/4.3/3.4/ was intended in the above)

I thought it would be worth sketching out my understanding of the
informal process we have for people to pick holes in. I've tried to
stick to what we actually do rather than defining policy.

Ian.

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

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

Each such branch is in in its own mercurial repository
xen-X.Y-testing.hg. Releases 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 repo 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 IIRC) and then the
4.0 branch was been retired.

        XXX how did Jan become stable maintainer, I think he just
        volunteered at the developer meeting and was accepted via the
        usual consensus driven approach? Lets try:

Each stable branch has a maintainer who is nominated/volunteers and is
accepted via consensus among the maintainers and committers (XXX or just
committers?). For the branches maintained by Xen.org this would usually
be one of the xen-unstable committers or maintainers. However community
members can step up to maintain a release once Xen.org no longer does so
(e.g. as happened with Keith and xen-3.4-testing.hg).

Currently Jan Beulich is the stable maintainer for both 4.1-testing and
4.2-testing having taken over from Keir Fraser when 4.2.0 was released.
Jan delegates tools backports to Ian Jackson. Community member Keith
Coleman continues to maintain the 3.4-testing branch (XXX does he
still?) which he took over when 4.1.0 was released.

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