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: Peter Maydell
Subject: Re: [Qemu-devel] proposed release timetable for 2.8
Date: Tue, 6 Sep 2016 13:43:35 +0100

On 6 September 2016 at 13:40, Markus Armbruster <address@hidden> wrote:
> Peter Maydell <address@hidden> writes:
>
>> On 6 September 2016 at 11:33, Kevin Wolf <address@hidden> wrote:
>>> Am 05.09.2016 um 13:10 hat Peter Maydell geschrieben:
>>>> 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.
>>
>> We already do (informally) once we're a way into the hard freeze.
>> Bug reports (and fixes for them) arrive all the time, and at
>> a rate such that if we allowed any bug fix into the
>> tree during freeze we would never have a period of a week
>> without new bugfixes going in that allowed us to actually
>> release.
>>
>> If a bug went unnoticed and unfixed for almost the whole release
>> cycle, this is a good sign that it's actually not all that
>> prominent to users; so it's a reasonably good, objective,
>> and easy to apply metric for restricting bug fixes to "only
>> important bug fixes".
>
> In short, we use common sense to throttle the flow of bug fixes, so we
> can get a release out of the door.

Exactly. The question I was asking above can be rephrased as
"if we apply that throttling more strictly and sooner, would
we get a release faster?".

-- PMM



reply via email to

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