From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Kurth Subject: Re: Notes from Xen BoF at Debconf15 Date: Tue, 8 Sep 2015 11:15:21 +0100 Message-ID: References: <1441704296.24450.24.camel@citrix.com> <55EECAE002000078000A0A83@prv-mh.provo.novell.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZZFw0-0004oW-JH for xen-devel@lists.xenproject.org; Tue, 08 Sep 2015 10:15:28 +0000 Received: by wiclk2 with SMTP id lk2so109434723wic.1 for ; Tue, 08 Sep 2015 03:15:26 -0700 (PDT) In-Reply-To: <55EECAE002000078000A0A83@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Debian Xen Team , Ian Campbell , xen-devel List-Id: xen-devel@lists.xenproject.org > On 8 Sep 2015, at 10:47, Jan Beulich wrote: > >>>> On 08.09.15 at 11:24, wrote: >> Release cycle >> ============= >> >> Waldi commented that the stable release cycle was too long. Would like >> to see a release after any large security update. >> >> We asked if the RCs for stable releases were valuable, the answer was >> "not so much". >> >> Waldi would prefer to avoid cherry-picking security fixes if possible. >> >> We asked if we thought Xen stable releases could be added to Debian >> point releases. Waldi thought they likely could be, citing the >> inclusion of Linux stable releases in point releases. >> >> Our stable releases follow a similar set of rules to Linux, we think >> we implement them more faithfully (less feature or feature-like >> backports) >> >> ACTION: Talk to Jan about making changes to stable release process. > > That's kind of the opposite of what we quite recently changed to > (a [hopefully] more predictable four month cycle). Apart from the > question what "large" is, doing a release after any large security > update seems unreasonable to me (not only because of giving up > the predictability, but also because of the overhead involved, > which is there even if we ditched the RCs). I suppose the question is what the real problem for distros is: If it is the process of cherry picking and merging, then we could create a tag on a stable branch more frequently (e.g. every month), which makes it easier for distros to consume a number of security fixes, while not creating all the overhead of creating a release. Whether such a tagged stable branch is an RC (without a tarball) or not, would be a different question. > I have to admit that I > fail to see why Debian would be different than other distros, all > cherry picking security fixes until a new stable release becomes > available. If otoh other major distros voiced similar desires, I > think we'd have to once again re-think our stable release cadence. A fully tested maintenance release, created more frequently would be a lot more challenging and require a lot more effort. I do agree with Jan that we ought to approach other distros and then re-think. Lars