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: Markus Armbruster
Subject: Re: [Qemu-devel] proposed release timetable for 2.8
Date: Mon, 05 Sep 2016 14:09:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Peter Maydell <address@hidden> writes:

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

Almost 300 commits to classify.  I'm afraid that's too tedious even for
me.

We could require such a classification for acceptance post 2.8-rc0.
Spreads the work.



reply via email to

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