On 25.11.20 14:48, Ian Jackson wrote: > Andrew Cooper , > George Dunlap , > Jan Beulich , > Julien Grall , > Stefano Stabellini , > =?iso-8859-1?Q?J=FCrgen_Gro=DF?= , > Paul Durrant , > Wei Liu > FCC: ~/mail/Outbound > --text follows this line-- > Hi. I've done a little bit of consultation with previous release > managers, and reviewed various list archives and calendars. These > consultations seemed to suggest some folklore that wasn't captured in > our process doc - hence the proposed patch, below. > > I would like to tentatively propose the following schedule and > policies for Xen 4.15. > > If you have opinions, please comment as soon as you can so that we can > have an open dialogue. Comments must be submitted at the very latest > by 1700 UTC on Wednesday the 2nd of December. > > Having never done this before, I am particularly interested in > comments from previous release managers. > > ** DRAFT ** > > Friday 8th January Last posting date > > Patches adding new features should be posted to the mailing list > by this cate, although perhaps not in their final version. > > Friday 22nd January Feature freeze > > Patches adding new features should be committed by this date. > Straightforward bugfixes may continue to be accepted by > maintainers. > > Friday 12th February **tentatve** Code freeze > > Bugfixes only, all changes to be approved by the Release Manager. > > Week of 12th March **tentative** Release > (probably Tuesday or Wednesday) > > Any patches containing substantial refactoring are to treated as > new features, even if they intent is to fix bugs. > > Freeze exceptions will not be routine, but may be granted in > exceptional cases for small changes on the basis of risk assessment. > Large series will not get exceptions. Contributors *must not* rely on > getting, or expect, a freeze exception. > > Chinese New Year falls around the 11th-19th of February this year. In > my plan above, that falls within the hard code freeze period. If we > don't manage to get the tree to an acceptable quality level by the > tentative codefreeze and release dates above, these dates will slip. > > I have not yet started tracking "big ticket" items, and bugs. I > expect to start doing that starting after Christmas. NB the primary > responsibility for driving a feature's progress to meet the release > schedule, lies with the feature's proponents. > > If as a feature proponent you feel your feature is at risk and there > is something the Xen Project could do to help, please consult me or > the Community Manager. In such situations please reach out earlier > rather than later. > > ** END OF DRAFT ** > > Thanks, > Ian. > >>From b34f4ddace0b8d76d8c340a46288a2db79c99460 Mon Sep 17 00:00:00 2001 > From: Ian Jackson > To: xen-devel@lists.xenproject.org > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Julien Grall > Cc: Stefano Stabellini > Date: Wed, 25 Nov 2020 13:22:08 +0000 > Subject: [PATCH] xen-release-management doc: More info on schedule > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > This documents our practice, established in 2018 > https://lists.xen.org/archives/html/xen-devel/2018-07/msg02240.html > et seq > > CC: Jürgen Groß > CC: Paul Durrant > CC: Wei Liu > Signed-off-by: Ian Jackson > --- > docs/process/xen-release-management.pandoc | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/docs/process/xen-release-management.pandoc b/docs/process/xen-release-management.pandoc > index e1aa1eda8f..a5d70fed67 100644 > --- a/docs/process/xen-release-management.pandoc > +++ b/docs/process/xen-release-management.pandoc > @@ -15,8 +15,10 @@ that they can have an idea what to expect from the Release Manager. > > # Xen release cycle > > -The Xen hypervisor project now releases every 8 months. The actual release date > -depends on a lot of factors. > +The Xen hypervisor project now releases every 8 months. We aim to > +release in the first half of March/July/November. These dates have > +been chosen to avoid major holidays and cultural events; if one > +release slips, ideally the previous release cycle would be shortened. s/previous/following/ Maybe add a reference to the mail thread in the xen-devel archives? > > We can roughly divide one release into two periods. The development period > and the freeze period. The former is 6 months long and the latter is about 2 > @@ -33,6 +35,12 @@ During freeze period, the tree is closed for new features. Only bug fixes are > accepted. This period can be shorter or longer than 2 months. If it ends up > longer than 2 months, it eats into the next development period. > > +The precise release schedule depends on a lot of factors and needs to > +be set afresh by the Release Manager in each release cycle. When the > +release is in March, particular consideration should be given to the > +Chinese New Year holidaty which will then typically occur curing the s/holidaty/holiday/ > +freeze, so the freeze should probably be extended to compensate. > + > # The different roles in a Xen release > > ## Release Manager > Juergen