From: Luiz Capitulino <lcapitulino@redhat.com>
To: Fred Leeflang <fredl@dutchie.org>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Paul Brook <paul@codesourcery.com>,
kvm-devel <kvm@vger.kernel.org>,
Aurelien Jarno <aurelien@aurel32.net>,
Andrzej Zaborowski <balrogg@gmail.com>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
Blue Swirl <blauwirbel@gmail.com>, malc <av1474@comtv.ru>
Subject: Re: [Qemu-devel] Release plan for 0.12.0
Date: Wed, 30 Sep 2009 12:26:17 -0300 [thread overview]
Message-ID: <20090930122617.40ebe188@doriath> (raw)
In-Reply-To: <30defc5b0909300803y4edcfca3p7ca2a7ee079d72a7@mail.gmail.com>
On Wed, 30 Sep 2009 17:03:23 +0200
Fred Leeflang <fredl@dutchie.org> wrote:
> 2009/9/30 Anthony Liguori <aliguori@us.ibm.com>
>
> > Luiz Capitulino wrote:
> >
> >> On Tue, 29 Sep 2009 18:54:53 -0500
> >> Anthony Liguori <aliguori@us.ibm.com> wrote:
> >>
> >>
> >>
> >>> I think aiming for early to mid-December would give us roughly a 3 month
> >>> cycle and would align well with some of the Linux distribution cycles. I'd
> >>> like to limit things to a single -rc that lasted only for about a week.
> >>> This is enough time to fix most of the obvious issues I think.
> >>>
> >>>
> >>
> >> How do you plan to do it? I mean, are you going to create a separate
> >> branch
> >> or make master the -rc?
> >>
> >> Creating a separate branch (which is what we do today, iiuc) makes it
> >> get less attention, freezing master for a certain period is the best
> >> way to stabilize.
> >>
> >> Is this what you had in mind?
> >>
> >>
> > What do people think?
> >
> > One reason I branch is because some people care a bit less about releases
> > so it makes the process non-disruptive to them. If the other maintainers
> > agreed though, I would certainly like to have the master branch essentially
> > frozen for the week before the release.
> >
>
> freezing is only neccesary if you need time to gather all the patches, build
> and test them together etc.
Not exactly, freezing is done to stop/slowdown writing new code and focus
on bug fixing for a period of time.
This is not only needed for a release, but projects should always try
to find the best balance between 'number of bugs' and 'feature addition rate'.
> If you don't feel you or the developers need to
> do that to get a reliable release out I think it only halts developers
> without any clear reason to do so. Calling 'attention' to a release is not a
> clear reason IMO.
Having a functional and relatively stable release is not only
important, but it's the ultimate goal IMO.
Obviously we should take care not to take extremes. No QEMU release
will be 100% bug free, that's why we have stables.
next prev parent reply other threads:[~2009-09-30 15:26 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-29 23:54 Release plan for 0.12.0 Anthony Liguori
2009-09-30 0:20 ` Dustin Kirkland
2009-09-30 2:18 ` Anthony Liguori
2009-09-30 2:28 ` [Qemu-devel] " Isaku Yamahata
2009-09-30 13:03 ` Anthony Liguori
2009-09-30 13:43 ` Michael S. Tsirkin
2009-09-30 5:17 ` Amit Shah
2009-09-30 13:04 ` Anthony Liguori
2009-09-30 13:37 ` Amit Shah
2009-09-30 14:47 ` Anthony Liguori
2009-09-30 14:50 ` Amit Shah
2009-09-30 6:41 ` [Qemu-devel] " Avi Kivity
2009-09-30 13:05 ` Anthony Liguori
2009-10-01 21:13 ` Luiz Capitulino
2009-10-03 10:04 ` Avi Kivity
2009-10-05 12:43 ` Luiz Capitulino
2009-10-05 13:52 ` Avi Kivity
2009-09-30 13:31 ` Luiz Capitulino
2009-09-30 8:53 ` Michael Tokarev
2009-09-30 9:01 ` Avi Kivity
2009-09-30 9:31 ` Carl-Daniel Hailfinger
2009-09-30 13:07 ` Anthony Liguori
2009-09-30 15:59 ` Carl-Daniel Hailfinger
2009-09-30 19:25 ` Blue Swirl
2009-09-30 13:30 ` Luiz Capitulino
2009-09-30 14:45 ` Anthony Liguori
2009-09-30 15:03 ` Fred Leeflang
2009-09-30 15:26 ` Luiz Capitulino [this message]
2009-09-30 17:03 ` Juan Quintela
2009-09-30 19:28 ` [Qemu-devel] " Gerd Hoffmann
2009-10-03 4:28 ` TAKEDA, toshiya
2009-10-08 13:55 ` [Qemu-devel] " Jens Osterkamp
2009-10-08 14:21 ` Anthony Liguori
2009-10-14 13:09 ` [Qemu-devel] " Arnd Bergmann
2009-10-14 13:53 ` Anthony Liguori
2009-10-14 14:01 ` Michael S. Tsirkin
2009-10-14 14:04 ` Michael S. Tsirkin
2009-10-14 13:21 ` Michael S. Tsirkin
2009-10-14 14:17 ` Anthony Liguori
2009-10-14 14:24 ` Michael S. Tsirkin
2009-10-14 15:19 ` [Qemu-devel] " Jamie Lokier
2009-10-14 15:50 ` Michael S. Tsirkin
2009-10-14 21:10 ` [Qemu-devel] " Sridhar Samudrala
2009-10-14 22:53 ` Raw vs. tap (was: Re: Re: Release plan for 0.12.0) Anthony Liguori
2009-10-15 6:36 ` Raw vs. tap (was: Re: [Qemu-devel] " Mark McLoughlin
2009-10-15 7:56 ` Raw vs. tap (was: " Michael S. Tsirkin
2009-10-15 13:32 ` Raw vs. tap Anthony Liguori
2009-10-15 15:04 ` Michael S. Tsirkin
2009-10-15 15:18 ` Anthony Liguori
2009-10-15 15:48 ` Michael S. Tsirkin
2009-10-15 18:37 ` Anthony Liguori
2009-10-15 22:08 ` Michael S. Tsirkin
2009-10-18 10:05 ` Michael S. Tsirkin
2009-10-15 7:51 ` [Qemu-devel] Re: Release plan for 0.12.0 Michael S. Tsirkin
2009-10-20 6:33 ` Takahiro Hirofuchi
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=20090930122617.40ebe188@doriath \
--to=lcapitulino@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=aurelien@aurel32.net \
--cc=av1474@comtv.ru \
--cc=balrogg@gmail.com \
--cc=blauwirbel@gmail.com \
--cc=edgar.iglesias@gmail.com \
--cc=fredl@dutchie.org \
--cc=kvm@vger.kernel.org \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox