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.
>>> On 26.11.12 at 16:58, Ian Campbell <Ian.Campbell@citrix.com> 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 stableDid 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.
On Mon, 2012-11-26 at 16:37 +0000, Jan Beulich wrote:> >>> On 26.11.12 at 16:58, Ian Campbell <Ian.Campbell@citrix.com> 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@kernel.org"? 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@xen.org, 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 listAgreed.> (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.
>>> On 26.11.12 at 17:45, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Mon, 2012-11-26 at 16:37 +0000, Jan Beulich wrote: >> >>> On 26.11.12 at 16:58, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> > 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 ;-)Oh, sorry, I thought it to be clear that I wanted "stable" replaced by "major" (because that''s where a regression would occur with a fix that wasn''t a backport). But as always, I should have made this explicit.>> > 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?Maybe specifically on the stable branches?> I also wondered if it might be useful to have a greppable string, like > Linux''s "CC: stable@kernel.org"? 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@xen.org, directed to a blackhole if > necessary.Since we don''t generally include Cc-s in commit messages, I don''t think that would help much. But I''m not opposed to this either. Jan
On Mon, 2012-11-26 at 16:37 +0000, Jan Beulich wrote:> >>> On 26.11.12 at 16:58, Ian Campbell <Ian.Campbell@citrix.com> wrote:> > 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 listHow about this, I don''t think we need to explicitly consider the "please revert it" case -- should be self evident? 8<---------------------------------------- Changesets are included in the stable branch at the discretion of the branch maintainer. 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.
>>> On 26.11.12 at 18:24, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Mon, 2012-11-26 at 16:37 +0000, Jan Beulich wrote: >> >>> On 26.11.12 at 16:58, Ian Campbell <Ian.Campbell@citrix.com> wrote: > >> > 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 > > How about this, I don''t think we need to explicitly consider the "please > revert it" case -- should be self evident?Looks good to me. Jan> 8<---------------------------------------- > > Changesets are included in the stable branch at the discretion of the > branch maintainer. > > 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.
> (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? 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. Regards Lars On Mon, Nov 26, 2012 at 3:58 PM, Ian Campbell <Ian.Campbell@citrix.com>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_Releasessays: > 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@lists.xen.org http://lists.xen.org/xen-devel
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 typoFixed.> 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@citrix.com> 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. > > >
>>> On 27.11.12 at 11:52, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Tue, 2012-11-27 at 09:56 +0000, Lars Kurth wrote: >> > 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?I''m not certain tracking stable branch maintainers in the -unstable MAINTAINERS file is of much use, plus I would be afraid this would then be forgotten to get updated upon releases (and hence getting stale quite quickly). Jan
On Mon, 2012-11-26 at 16:58 +0000, Jan Beulich wrote:> >>> On 26.11.12 at 17:45, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Mon, 2012-11-26 at 16:37 +0000, Jan Beulich wrote: > >> >>> On 26.11.12 at 16:58, Ian Campbell <Ian.Campbell@citrix.com> wrote: > >> > 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 ;-) > > Oh, sorry, I thought it to be clear that I wanted "stable" replaced > by "major" (because that''s where a regression would occur with a > fix that wasn''t a backport). But as always, I should have made this > explicit.Got it, yes you are absolutely right. I was a bit worried about "major" implying the X being bumped, not just the Y. But we don''t really distinguish these (cf the 4.0 bump being nothing especially significant) so I think I worried needlessly.> > >> > 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? > > Maybe specifically on the stable branches?Yes, or both?> > I also wondered if it might be useful to have a greppable string, like > > Linux''s "CC: stable@kernel.org"? 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@xen.org, directed to a blackhole if > > necessary. > > Since we don''t generally include Cc-s in commit messages, I don''t > think that would help much. But I''m not opposed to this either.I guess we could always start. I think its pretty likely that having switched to git folks are likely to start making more use of this (IMHO very convenient) feature of git format-patch/send-email anyway. Ian.
On Tue, 2012-11-27 at 10:57 +0000, Jan Beulich wrote:> >>> On 27.11.12 at 11:52, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Tue, 2012-11-27 at 09:56 +0000, Lars Kurth wrote: > >> > 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? > > I''m not certain tracking stable branch maintainers in the -unstable > MAINTAINERS file is of much use, plus I would be afraid this would > then be forgotten to get updated upon releases (and hence getting > stale quite quickly).My theory was that people looking in unstable for the fix the their problem might just look in to the unstable MAINTAINERS file. In reality I suspect no one ever looks in there for any reason anyway (we don''t really have a culture of CCing maintainers). We could at least include a reference in unstable to the stable backport docs, even if we don''t list specific maintainers. Ian.
>>> On 27.11.12 at 12:04, Ian Campbell <Ian.Campbell@citrix.com> wrote: > We could at least include a reference in unstable to the stable backport > docs, even if we don''t list specific maintainers.Yes, that we should do. Jan
> 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?Let''s put it on the wiki say under "Xen Maintenance Releases". I lost track a little of the changes (but then I am side-tracked with the XCP release), so why don''t you put it on the wiki for now. I can handle the formatting and link to the page from xen.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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.
On Tue, 2012-11-27 at 15:40 +0000, Ian Campbell wrote:> Lets do it in the stable branch version for now with a reference. I''ll > send out some patches.[...]> 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.Both of these are now done.