Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

[Steven Haigh <netwiz@xxxxxxxxx>]

On Thursday, 5 July 2018 1:47:27 AM AEST Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [Notes for xen summit 2018 design 
session] Process changes: is the 6 monthly release Cadence too short, Security 
Process, ..."):
> > I seem to recall saying that even if we agreed that moving to continuous
> > delivery was a goal we wanted to pursue, we would still be several years
> > away from achieving anything like it; and so in the mean time, it would
> > probably make sense to move back to a 9-month cycle while we attack the
> > problem.
> Another thing that is that as our window of N years'
> security-supported releases has filled up with ~6-month releases,
> there are more of them.
> 
> I know we had concerns that this makes backporting harder.  I'm not
> really sure that's true.  The total amount of backporting lossage
> (merge conflicts etc.) is the same, and trivial automatic backports
> are nearly no work.
> 
> But one thing that is noticeable is that this significantly increases
> our test load when a security update comes out.  Each
> security-supported branch gets updates, and osstest suddenly needs to
> test them all.

I did like the idea of an 'LTS' vs 'testing' release. The idea that odd / even 
or similar varied in lifecycle - allowing entire versions to be killed off 
rapidly.

If we had 'LTS' support at 2 (or more?) years, and 'testing' support at 6 (or 
less?) months, would this help?

I guess the idea would be that the 'testing' versions are where all the rapid 
features are added, which is then 'frozen' into an LTS release at some point 
to only get security fixes via point releases (ala linux kernel version type 
bumping).

Is this even practical? I guess this would depend on how often an LTS release 
is spawned...

-- 
Steven Haigh

📧 netwiz@xxxxxxxxx       💻 https://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