[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.