All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Xen 4.12 release planning
Date: Fri, 27 Jul 2018 09:51:47 +0200	[thread overview]
Message-ID: <f78a2c5a-6f78-d11d-0f13-6240d47c6642@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1807261510301.20701@sstabellini-ThinkPad-X260>

On 27/07/18 00:13, Stefano Stabellini wrote:
> On Wed, 25 Jul 2018, Juergen Gross wrote:
>> Its time to plan the Xen 4.12 release dates.
>>
>> There have been concerns with the schedule of 6 months between releases,
>> as this scheme is leading to too many supported versions of Xen at a
>> time. The needed resources to backport bug fixes and security fixes as
>> well as doing the tests for all those releases are a limiting factor to
>> push out the current main release as well as point releases on time.
>>
>> After some discussions at the Xen developer summit, on xen-devel and
>> between the committers a slightly longer release cycle of 8 or 9 months
>> was suggested.
>>
>> With 18 months of full support and 36 months of security support the
>> number of concurrent supported releases will be the same with either 8
>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>> Having only 3 possible times in the year for a release will make it
>> easier to avoid major holiday seasons.
>>
>> In case there is no objection I'm planning Xen 4.12 with:
>>
>> * Last posting date: December 14th, 2018
>> * Hard code freeze: January 11th, 2019
>> * Release: March 7th, 2019
>>
>> Release of Xen 4.13 would then be early November 2019, 4.14 at early
>> July 2020.
> 
> Given the holdidays season (it is not just Julien going on vacation but
> pretty much everybody), wouldn't it be better to move the hard code
> freeze by a couple of weeks? For instance Jan 25th? We can still keep
> the release date as Mar 7th, there should be still enough time?

I don't think planning with a 6 week freeze period is a good idea. The
last releases took longer than 2 months.

We could slip the complete release by 2 weeks, of course. In this case
I'd move the last posting date to January. So something like:

* Last posting date: January 11th, 2019
* Hard code freeze: January 25th, 2019
* Release: March 21st, 2019

Risks for that schedule are:
- last posting date short after holiday season - is that really a
  problem?
- Chinese new year rather soon after start of freeze period
- planned release date rather close to eastern

Opinions?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-07-27  7:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-25  7:19 Xen 4.12 release planning Juergen Gross
2018-07-25  8:15 ` Julien Grall
2018-07-25  8:19   ` Andrew Cooper
2018-07-25  9:22     ` Juergen Gross
2018-07-25 11:24       ` George Dunlap
2018-07-25 11:30         ` Andrew Cooper
2018-07-25 11:34           ` George Dunlap
2018-07-25 11:36             ` Andrew Cooper
2018-07-25 11:34           ` Juergen Gross
2018-07-25 11:37             ` Juergen Gross
2018-07-25 11:39         ` Lars Kurth
2018-07-25 11:45           ` Juergen Gross
2018-07-25 11:51             ` Lars Kurth
2018-07-25 11:58               ` Juergen Gross
2018-07-26 22:13 ` Stefano Stabellini
2018-07-27  7:51   ` Juergen Gross [this message]
2018-07-27 10:32     ` Lars Kurth
2018-07-27 10:43       ` Juergen Gross
2018-07-27 15:50         ` Stefano Stabellini
2018-07-27 16:10           ` Juergen Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f78a2c5a-6f78-d11d-0f13-6240d47c6642@suse.com \
    --to=jgross@suse.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.