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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Jul 05, 2018 at 10:43:38AM +0200, Roger Pau Monné wrote:
> On Thu, Jul 05, 2018 at 09:19:10AM +0100, Wei Liu wrote:
> > On Thu, Jul 05, 2018 at 10:06:52AM +0200, Roger Pau Monné wrote:
> > > On Thu, Jul 05, 2018 at 08:53:51AM +0100, Wei Liu wrote:
> > > > On Wed, Jul 04, 2018 at 03:26:16PM +0000, George Dunlap wrote:
> > > > > So a fair amount of the discussion was about what it would look like,
> > > > > and what it would take, to make it such that almost any push from
> > > > > osstest (or whatever testing infrasctructure we went with) could
> > > > > reasonably be released, and would have a very low expectation of
> > > > > having extraneous bugs.
> > > > 
> > > > I would also like to advocate changing the mentality a bit. The current
> > > > mentality is that "we want to be reasonably sure there is low
> > > > expectation of bugs before we can release". Why not change to "we
> > > > release when we're sure there is definitely improvement in the tree
> > > > compared to last release"?
> > > 
> > > The current guideline is quite objective, if there are no reported
> > > bugs and osstest flight doesn't show any regressions we are ready to
> > > release. OTOH how should the improvements to the tree be quantized and
> > > measured?
> > 
> > Say, a security bug is fixed? A major bug is closed?
> 
> I think this is still quite subjective, whereas the previous criteria
> was objective.
> 

They are orthogonal. We can still wait a bit until osstest reports no
regression and noone reports bugs.

> Who will take the decision of whether a bug is major or not?

That's as subjective as why a release should be done in 6 months or 9
months but not 1 year or 2 years.

> 
> > > 
> > > At any point during the development or the release process the tree
> > > will contain improvements in some areas compared to the last
> > > release.
> > 
> > Yes, that is right. That's what CD does, right?
> 
> I thin so, but I'm not an expert on development techniques TBH :).
> 
> IMO one of the problems with Xen is that users don't tend to test
> master often, I assume this is because Xen is a critical piece of
> their infra, and they require it to be completely stable. Not everyone
> can effort an extra box just for testing Xen master. I'm not sure this
> is going to change a lot even if nightly builds are provided.

I think you underestimate the number of people wanting to use nightly
builds. I think XenServer.org is a good example?

Wei.

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