qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] proposed release timetable for 2.8


From: Kevin Wolf
Subject: Re: [Qemu-devel] proposed release timetable for 2.8
Date: Tue, 6 Sep 2016 12:33:11 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 05.09.2016 um 13:10 hat Peter Maydell geschrieben:
> On 1 September 2016 at 12:18, Peter Maydell <address@hidden> wrote:
> > I know 2.7 isn't quite out the door yet, but I figured we should
> > kick off the discussion of 2.8's schedule. At the QEMU Summit there
> > was some discussion on how we're doing with releases, and I think
> > the consensus view was that we should try to cut down the softfreeze
> > period and also be stricter about (a) making sure pull requests get
> > in in a timely way before rc0 and (b) we don't take new features
> > during softfreeze.
> 
> It occurs to me that if anybody has the patience to do some tedious
> data-mining, it would be interesting to know for all the commits
> that went in after rc0 whether they were:
>  * fixing bugs that were already present in our previous release
>  * fixing regressions (ie bugs introduced after the previous release)
>  * fixing bugs in features that are new in this release
>  * new features
>  * fixing bugs introduced by other post-rc0 commits
>  * security fixes
> 
> ie if we were stricter about "no commits unless they're fixes for
> regressions, fixes for things new in this release or security fixes",
> would this reduce the number of commits we do post-freeze much?

I don't think we should leave a bug intentionally unfixed even though
there is a patch, just because it was already broken in the last
release.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]