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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.11.12 at 16:58, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 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.

Should we indeed switch to git (which I'm in no way trying to
accelerate), one of the points I actually wanted to bring up is
this very duplication. I'm not sure about Mercurial in this regard,
but git certainly can easily deal with all branches in a single repo
(and the extra data volume and traffic shouldn't be so high that
it could be expected to cause problems to anyone).

> Releases happen roughly every 3 months. The first

... are intended to ...

> 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

Did you mean "major" here?

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

I think we should explicitly require the person expected to do the
backport to be Cc-ed; I for myself don't get around to read _all_
mails on xen-devel, and hence with a badly chosen subject it is not
impossible (albeit also not likely) for me to miss such a request
otherwise.

Furthermore, the branch maintainer should imo explicitly be given
discretion to pull in patches without explicit request on the list (I
have been actively doing so thus far, and apparently not without
success, considering that post-RC1 there were no further
hypervisor side backports requested for either branch so far). In
the hopefully not very likely event that too much was backported,
a revert request would then need to be sent/discussed instead.

Jan

> 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