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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Jul 05, 2018 at 09:47:43AM +0100, Wei Liu wrote:
> 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.

But that's a subjective one time decision that once taken then the
project sticks to. Deciding when to release in your scenario involves
at least one subjective decision before each release.

As an example just see how much opinions are we having about changing
the release cycle. Imagine we had this every time the project needs to
decide whether to release or not.

> > 
> > > > 
> > > > 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?

OK, maybe. The above was mostly my opinion, but I agree I don't know
that much. I think xenserver nightly builds are much more stable,
because the hypervisor there doesn't change that often and it's based
on a cured stable branch.

Roger.

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