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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2012-11-26 at 16:37 +0000, Jan Beulich wrote:
> >>> 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).

I think a single xen.git would make sense, and indeed the current git
mirror implements this.

> 
> > Releases happen roughly every 3 months. The first
> 
> ... are intended to ...

ACK ;-)

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

Where? Before "regressions"? I'd like to think we were striving to avoid
regressions of either sort ;-)

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

That makes sense to me. Should we add entries to MAINTAINERS to cover
stable trees as well?

I also wondered if it might be useful to have a greppable string, like
Linux's "CC: stable@xxxxxxxxxx"? AIUI the Linux stable guys don't
actually use this as a mailing list, even though it technically does
exist as such, instead they use it as grep fodder for their tooling. We
could certainly setup stable@xxxxxxx, directed to a blackhole if
necessary.

> Furthermore, the branch maintainer should imo explicitly be given
> discretion to pull in patches without explicit request on the list

Agreed.

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

Ack.

I'll update and resend without your comments addressed, although perhaps
not today.

Ian.


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