All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Julien Grall <julien.grall@linaro.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	"committers@xenproject.org" <committers@xenproject.org>
Subject: Re: Xen release cycle revisited
Date: Thu, 14 Dec 2017 12:38:49 +0100	[thread overview]
Message-ID: <07c2bf19-2ad0-248f-70cb-72896a26c1e3@suse.com> (raw)
In-Reply-To: <55a31b83-a691-90e5-1a3e-a7532a49e30a@linaro.org>

On 14/12/17 12:28, Julien Grall wrote:
> 
> 
> On 14/12/17 07:56, Juergen Gross wrote:
>> Hi all,
> 
> Hi Juergen,
> 
> I would recommend to CC committers on that thread, so your thread don't
> get lost in the xen-devel meanders :).
> 
>> with 4.10 more or less finished it is time to plan for the next release
>> 4.11. Since 4.7 we are using a 6 month release cycle [1] targeting to
>> release in June and December.
>>
>> While this worked reasonably well for 4.7, 4.8 and 4.9 we had some
>> difficulties with 4.10: bad luck with security patch timing shifted the
>> 4.10 release more towards mid of December. Doing thorough testing of the
>> latest security patches and trying to release at least 10 days before
>> Christmas seemed to be almost mutually exclusive goals.
>>
>> So what do we learn from this experience?
>>
>> 1. Should we think about other planned release dates (e.g. May and
>>     November - would that collide with any holiday season)?
>>
>> 2. Shouldn't we have tried to include the latest security patches in
>>     4.10, resulting in the need for 4.10.1 at once?
> 
> I am not sure to understand this questions here.

Hmm, yes, this is somehow garbled.

Next try:

2. Should we have released 4.10 without those late security patches,
   resulting in the need for 4.10.1 at once?

> 
>>
>> 3. Should we let the release slip for almost a month in such a case?
> 
> The problem is XSAs can happen at any time. Let's imagine we decided to
> release in January, what if a new security was discovered during
> christmas? Are we going to slip the release again?

Go back to 2. :-)

> 
>>
>> 4. Should we try harder to negotiate embargo dates of security issues to
>>     match the (targeted) release dates?
> 
> Those 4 XSAs was first released under embargoed a couple of days before
> the targeted release dates.
> 
> The usual embargo period is 2 weeks. I think it would be difficult to
> request a shorter embargo period because downstream product need time to
> apply/test the security fixes.

Right. What about a longer embargo so that it ends well after the
release date? Last minute XSAs just before a 2-3 week period where
a release can't happen (like at Xmas) are the problem.


Juergen

> 
>>
>> 5. Should we modify the development/hardening periods?
>>
>> For 4.11 we shouldn't have this problem: while targeted for releasing in
>> early June it wouldn't be a nightmare to let it slip into July. 4.12
>> however will probably face the same problem again and we should prepare
>> for that possibility.
>>
>>
>> Juergen
>>
>> [1]: https://lists.xen.org/archives/html/xen-devel/2015-10/msg00263.html
> 
> Cheers,
> 


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

  reply	other threads:[~2017-12-14 11:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-14  7:56 Xen release cycle revisited Juergen Gross
2017-12-14 11:28 ` Julien Grall
2017-12-14 11:38   ` Juergen Gross [this message]
2017-12-14 12:43     ` Julien Grall
2017-12-14 13:13       ` Juergen Gross
2017-12-15 14:54         ` Juergen Gross
2017-12-18 14:56           ` George Dunlap
2017-12-18 15:57             ` Julien Grall
2017-12-18 16:10               ` Juergen Gross
2017-12-18 16:38                 ` Julien Grall
2017-12-18 18:32                   ` Juergen Gross
2017-12-18 20:27                     ` Julien Grall
2017-12-19  6:58                       ` Juergen Gross
2017-12-19  8:47                         ` Jan Beulich
2017-12-19 10:42                           ` Steven Haigh
2017-12-19 11:44                             ` George Dunlap
2017-12-19 12:25                               ` Steven Haigh
2017-12-18 16:53                 ` George Dunlap
2017-12-14 14:07     ` Jan Beulich
2017-12-14 14:11 ` Jan Beulich
2017-12-18 15:48   ` George Dunlap
2018-01-02 12:54 ` Lars Kurth
2018-01-02 13:10   ` Juergen Gross
2018-01-02 15:07   ` Steven Haigh
2018-01-02 16:22     ` Jan Beulich

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=07c2bf19-2ad0-248f-70cb-72896a26c1e3@suse.com \
    --to=jgross@suse.com \
    --cc=committers@xenproject.org \
    --cc=julien.grall@linaro.org \
    --cc=lars.kurth@citrix.com \
    --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.