All of lore.kernel.org
 help / color / mirror / Atom feed
From: Blue Swirl <blauwirbel@gmail.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Aurelien Jarno <aurelien@aurel32.net>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [RFC] Planning for 1.0 (and freezing the master branch)
Date: Sun, 14 Aug 2011 19:30:09 +0000	[thread overview]
Message-ID: <CAAu8pHsx9bNUorVNwdZYnv+rEKmLkJiS=AnUPFvZpKfppTSNRg@mail.gmail.com> (raw)
In-Reply-To: <4E47D1AC.70906@codemonkey.ws>

On Sun, Aug 14, 2011 at 1:46 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 08/12/2011 03:46 PM, Blue Swirl wrote:
>>
>> On Thu, Aug 11, 2011 at 9:54 PM, Gerd Hoffmann<kraxel@redhat.com>  wrote:
>>>
>>>  Hi,
>>>
>>>>> In general the idea is OK. Especially soft freeze could solve problems
>>>>> like those qemu-ga inclusion had.
>>>>>
>>>>> Two weeks for soft freeze would be close to OK but I think a month of
>>>>> hard freeze is too long. With the previous releases, the problems in
>>>>> stable were ironed out within a week or two. How about 2 + 2?
>>>>
>>>> I feel like 2 weeks was too short for this release and releases in the
>>>> past.
>>>
>>> Well, one reason for the release process not being that smooth is that a
>>> big
>>> pile of stuff was merged just before 0.15-rc0.  First because there was a
>>> noticable backlog due to maintainers vacation, and second because a bunch
>>> of
>>> people wanted there stuff be merged for 0.15.
>>>
>>> I think two weeks soft freeze and two weeks hard freeze should work
>>> reasonable well.  I think shorter release cycles will help too, so the
>>> pressure to get stuff in before the freeze is lower as the following
>>> release
>>> isn't that far away.
>>>
>>> So how about this:
>>>
>>>  - roughly four weeks development phase.
>>>  - two weeks soft freeze (aka no big stuff).
>>>  - two weeks hard freeze (aka bugfixes only).
>>
>> This 50% duty cycle would mean that for half of the time, people only
>> work within their forked trees and then try to merge these forks. I
>> think the rate should be something like 80% merging, 20% freeze, which
>> (with one month freeze) would be close to current speed of two
>> releases per year.
>>
>> I agree releasing more often is better, but for that to work, I'd go
>> for something like:
>> - 2 months development
>> - two weeks soft freeze
>> - fork stable rc0, release after 2 to 4 weeks
>
> Maybe something more like:
>
> 2 months development
> -rc0 goes out (master enters soft feature freeze)

Why an rc0 at this point? 0.15-rc0 was in a bad shape because it was
forked just after heavy development (ga etc). I'd nominate release
candidates only after soft freeze, then there would not be any major
changes. Though a rc0 could attract testing efforts from outside and
for those, the earlier the better.

> 2 weeks development in master, stabilization and careful consideration of
> new features
> -rc1 goes out (master enters hard feature freeze)
> 1 week stabilization
> -rc2 goes out
> 1 week stabilization
> -rc3 goes out, -rc3 becomes release

So at this point master would be released? What's the difference in
time between rc3 and release?

Overall this would only give a duty cycle of 67%. For 4 weeks total
freeze, the development would need to be 4 months for an 80% duty
cycle. But I think this version could work too.

> I think a shorter cycle could work better long term.  I think it needs to be
> done as part of the master branch though and I'd wait until 1.1 to implement
> it.
>
> Regards,
>
> Anthony Liguori
>

  reply	other threads:[~2011-08-14 19:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-11 13:46 [Qemu-devel] [RFC] Planning for 1.0 (and freezing the master branch) Anthony Liguori
2011-08-11 17:30 ` Blue Swirl
2011-08-11 18:21   ` Anthony Liguori
2011-08-11 21:54     ` Gerd Hoffmann
2011-08-12 20:46       ` Blue Swirl
2011-08-14 13:46         ` Anthony Liguori
2011-08-14 19:30           ` Blue Swirl [this message]
2011-08-15 17:59             ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAu8pHsx9bNUorVNwdZYnv+rEKmLkJiS=AnUPFvZpKfppTSNRg@mail.gmail.com' \
    --to=blauwirbel@gmail.com \
    --cc=anthony@codemonkey.ws \
    --cc=aurelien@aurel32.net \
    --cc=avi@redhat.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=jmforbes@linuxtx.org \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.