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

Fixed.

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

I think we could reasonably do both?

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

This second might make a reasonable independent wiki page?

> Otherwise this sounds like a good proposal and starting point. Thanks
> for putting it together.

No problem. Do you have any preference for formatting or want me to put
this anywhere in particular or will you just take the text and run with
it?

> 
> Regards
> Lars
> 
> 
> On Mon, Nov 26, 2012 at 3:58 PM, Ian Campbell
> <Ian.Campbell@xxxxxxxxxx> wrote:
>         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