(resending because the first one had corrupted email headers;
 please reply to this one and not the previous one)

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 <iwj@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@citrix.com>
Cc: Ian Jackson <iwj@xenproject.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>
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ß <jgross@suse.com>
CC: Paul Durrant <xadimgnik@gmail.com>
CC: Wei Liu <wl@xen.org>
Signed-off-by: Ian Jackson <iwj@xenproject.org>
---
 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.
 
 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
+freeze, so the freeze should probably be extended to compensate.
+
 # The different roles in a Xen release
 
 ## Release Manager
-- 
2.20.1

Hi Ian,

On 25/11/2020 13:56, Ian Jackson wrote:
>    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.
We have a quite a good features line-up on Arm for this release. 
Unfortunately, some of the Arm reviewers (including myself) will be 
unavailable until mid-January. I think this will likely impair what we 
can get in Xen 4.15.

I was going to suggest a different feature freeze date for Arm (IIRC we 
did that in 2018), but the implementation of IOREQ for Arm will touch 
also x86 (in order to make the existing code common).

Therefore, would it be possible to push the "Feature Freeze" by week?

Note that I am not suggesting to push the "Last posting date" as to 
avoid increasing pressure on the number of series to review.

Cheers,

-- 
Julien Grall

Julien Grall writes ("Re: Xen 4.15: Proposed release schedule"):
> Therefore, would it be possible to push the "Feature Freeze" by week?

Sure.  To expand on that: this was the only comment on my proposal,
and I'm happy to accept such a minor change.

Adjusting the LPD too, but not the other two tentative dates, leads to
this schedule:

   Friday 15th 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 29th 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)

Unless anyone has objections, I will declare this official, tomorrow.

Ian.