Re: [Xen-devel] Xen release cycle revisited

[Steven Haigh <netwiz@xxxxxxxxx>]

On Tuesday, 19 December 2017 10:44:04 PM AEDT George Dunlap wrote:
> On 12/19/2017 10:42 AM, Steven Haigh wrote:
> > On Tuesday, 19 December 2017 7:47:14 PM AEDT Jan Beulich wrote:
> >>>>> On 19.12.17 at 07:58, <jgross@xxxxxxxx> wrote:
> >>> My proposal addresses the 4.10 experience. I see the following
> >>> alternatives (assuming we want to keep the two releases per year
> >>> scheme):
> >>> 
> >>> 1. Leave everything as is
> >>> 
> >>>    Pro: seems to work for the June release
> >>>    Con: release date for the December release is risky
> >>> 
> >>> 2. Move releases one month earlier, freeze dates as well (my proposal)
> >>> 
> >>>    Pro: more time for release at end of the year
> >>>    Con: freeze date end of February at end of Chinese New Year holidays
> >>>    
> >>>         in some years (2018 not applicable, as we would move that
> >>>         release by 2 weeks only, so next time this will really hit us
> >>>         will be 2026, maybe a little bit in 2021)
> >>> 
> >>> 3. Move releases one month earlier, freeze dates before holidays
> >>> 
> >>>    Pro: developers won't have to let feature slip due to holiday
> >>>    Con: shorter development time for _all_ developers
> >>> 
> >>> 4. Keep the June release like today, move the December release 2 or 4
> >>> 
> >>>    weeks earlier
> >>>    Pro: all Pros of 1-3
> >>>    Con: every second release will have shorter development cycle
> >> 
> >> 5. Go to a yearly release cycle, with June as expected release date.
> >> At the risk of (still) being the only one to dislike the 6-month cycle,
> >> I have to say that there, at the moment, being 4 actively maintained
> >> stable branches and 6 security maintained ones is - just like I did
> >> anticipate back when we discussed the shortening of the cycle - a
> >> significant burden. And we haven't even reached the point yet
> >> where all security maintained branches are from the 6-month cycle.
> > 
> > I've gotta agree here - I've already been skipping releases to keep up.
> > 4.8
> > was a complete non-starter for me, and 4.10 might be the same. Its
> > exhausting.
> FWIW the CentOS Virt SIG had already decided to only consider updating
> every other release, back when the release cadence was 9 months (leaving
> a year and a half between upgrades).

Understandable.
 
> But of course, that's in part  because CentOS is meant to be "stodgy and
> reliable".  Fedora and Ubuntu, for instance, have 6-month release
> cycles.  It looks like Ubuntu 17.10 has Xen 4.9 in it; and there's no
> reason to think Ubuntu 18.04 LTS won't have 4.10 in it.

Agreed - but things like Fedora evolve pretty rapidly. I'm not sure Xen is in 
the same rapid development model - so I don't think we should follow suit in 
this. It would be more than reasonable to have, say, Xen 4.10.0 in one version 
of Fedora - and 4.10.2 in the next...

> Steven, when I glanced at your site it looked like you're actively
> supporting all versions of Xen you've ever released -- is that right?
> If so it's a lot more work than I think anyone else is doing. :-)

Correct. The only versions I don't support are EOL'ed versions and 4.8 - which 
I skipped due to workload.

This means the current build list is 4.5, 4.6, 4.7, 4.9 for both EL6 and EL7.

4.2 and 4.4 got EOL'ed a while back and I don't make them available anymore.

If I didn't miss a 4.8 and already had 4.10 out the door, then I'd be 
publishing 4.5, 4.6, 4.7, 4.8, 4.9 and 4.10. I'm not sure if that's feasible 
for anyone - let alone how it'd be managed effectively by the security team!

For me personally, December release dates for builds is horrible - so its 
likely just about any December release would be on the ignore list - hence I 
feel a single yearly release in July (+/- up to 2 months) would be fine as a 
target.

-- 
Steven Haigh

📧 netwiz@xxxxxxxxx       💻 http://www.crc.id.au
📞 +61 (3) 9001 6090    📱 0412 935 897

Attachment: signature.asc
Description: This is a digitally signed message part.

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