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:55:49AM +0200, Roger Pau Monné wrote:
> 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.

They are different issues.  Why would we argue over what to release or
not if the process is lightweight and releasing a new version is as easy
as pushing a tag?

I can think of major release being a problem because that affects how
many branches we support but point releases shouldn't be a point of
contention at all.

Wei.

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