From: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
To: Brian Jackson <iggy@theiggy.com>
Cc: Greg KH <greg@kroah.com>,
"Justin M. Forbes" <jmforbes@linuxtx.org>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan
Date: Thu, 02 Dec 2010 14:44:03 -0800 [thread overview]
Message-ID: <1291329843.15305.124.camel@haakon2.linux-iscsi.org> (raw)
In-Reply-To: <201012021606.49555.iggy@theiggy.com>
On Thu, 2010-12-02 at 16:06 -0600, Brian Jackson wrote:
> On Monday, November 29, 2010 11:42:49 am Anthony Liguori wrote:
> > Hi,
> >
> > 0.13 was a mess of a release (largely due to my lack of time) and I'd
> > like to get us back onto a predictable schedule.
> >
> > Here's what I propose:
> >
> > 12/6 - fork off stable-0.14 tree; simultaneously release qemu-0.14.0-rc0
>
>
> Have you considered a frozen master style release like other projects use?
> (Linux kernel, etc.)
>
> Every project I follow that does this "branch stable keep master moving"
> release thing has terrible releases every time. Patches don't make it back
> into stable,etc... Basically a lot of the same stuff we saw for 0.13.
>
>
Being fimilar with the kernel development process but not fimilar with
pre qemu-kvm.git development process, I would tend to agree with you
here..
Aside from that question, the one thing that is really useful in the
kernel development world is having an automated process to CC
stable@kernel.org in order to signal that a bugfix commit from 'master'
should be propigated down into stable trees and/or branches works very
well. This really simplfies the bug backport process, compared to say
each needing to do this by hand across a number of old stable versions.
This is how Greg-KH and kernel subsystem maintainers do things, and the
system works quite well with Greg tracking a handful of rolling stable
releases. I am not sure if Anthony already has such an automated system
in place for QEMU yet, but I think it would really be helpful for
propigating master bugfixes back into stable code.
Best,
--nab
prev parent reply other threads:[~2010-12-02 22:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-29 17:42 [Qemu-devel] [RFC] QEMU 0.14.0 release plan Anthony Liguori
2010-11-29 18:10 ` Alexander Graf
2010-11-29 19:29 ` Anthony Liguori
2010-11-29 19:58 ` Alexander Graf
2010-11-29 20:14 ` Anthony Liguori
2010-11-30 10:15 ` Kevin Wolf
2010-11-30 14:12 ` Anthony Liguori
2010-11-30 14:49 ` Kevin Wolf
2010-12-01 12:56 ` Luiz Capitulino
2010-12-02 16:13 ` Randy Smith
2010-12-02 22:06 ` Brian Jackson
2010-12-02 22:44 ` Nicholas A. Bellinger [this message]
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=1291329843.15305.124.camel@haakon2.linux-iscsi.org \
--to=nab@linux-iscsi.org \
--cc=greg@kroah.com \
--cc=iggy@theiggy.com \
--cc=jmforbes@linuxtx.org \
--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;
as well as URLs for NNTP newsgroup(s).