From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] RFC: This project needs a stable branch
Date: Thu, 15 Mar 2007 08:48:07 -0500 [thread overview]
Message-ID: <45F94E97.10502@codemonkey.ws> (raw)
In-Reply-To: <200703151111.04453.jseward@acm.org>
I'm not necessarily sure I agree that a stable branch is the best thing
to have (verses aiming for never introducing regressions).
I do agree that a bug tracker would be terribly useful for tracking
regressions. Bug trackers quickly get out of hand though unless someone
spends a lot of time keeping them tidy.
Any thoughts on the subject?
Regards,
Anthony Liguori
Julian Seward wrote:
> I am a great fan of QEMU, and have used it more or less continuously
> for the past 2+ years. Over that time I've installed and operated
> various Linux and Windows guests with varying degrees of success.
>
> The recently released 0.9.0 seems a big step forward in the
> stability/usability department, which is excellent. But there are
> still residual worries -- for example, qcow2 images corrupted for no
> obvious reason -- which, whilst a boring problem, is important for
> folks like me who want to run VMs 24x7 with the hope of complete
> reliability.
>
> Pretty much all mature projects which have achieved widespread usage
> have one or more stable branches along with the main development
> branch (trunk). Think GCC, the kernel, KDE, ... the list is endless.
>
> Maintaining a stable branch is extra hassle and overhead, but it is
> the standard way to operate, for reasons which are obvious: the
> majority of users care more about stability, reliability and usability
> than they do about the latest new features, and delivering stability
> from a branch used for bleeding-edge development work is pretty much
> impossible. That is not, of course, a criticism of the bleeding edge
> developers, since it is they who ultimately drive the project along.
>
> I am writing to propose that a stable branch be made from the 0.9.0
> release point. The aim would be to maximise stability for (IMO) the
> subset of functionality that has the largest potential user base:
> i386-softmmu + Accelerator and x86_64-softmmu + Accelerator, but
> excluding -kernel-kqemu due to limitations described in
> http://qemu.org/kqemu-doc.html#SEC7.
>
> Subsequent releases of the branch would contain no functionality
> enhancements, but just bug fixes, with the eventual aim of achieving
> 'it just works' status for any x86/x86_64 guest I try to install/run.
> I know that's a tall order, and that 0.9.0 may not be able to supply
> that for all guests. But it is an important goal to strive for.
>
> My impression is that (at least as I perceive it) the lack of emphasis
> on maximising stability on a stable branch, and the lack of a bug
> tracker, is artificially restricting QEMU's user base, and therefore
> indirectly its long term prospects. This is a shame, because QEMU is
> a very remarkable and useful project, which should be used (and
> usable) by everybody and anybody.
>
> J
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
next prev parent reply other threads:[~2007-03-15 13:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-15 11:11 [Qemu-devel] RFC: This project needs a stable branch Julian Seward
2007-03-15 13:48 ` Anthony Liguori [this message]
2007-03-15 14:11 ` Julian Seward
2007-03-15 14:53 ` Paul Brook
2007-03-15 15:34 ` Avi Kivity
2007-03-20 22:19 ` Julian Seward
2007-03-22 22:47 ` Rob Landley
2007-03-22 23:00 ` Johannes Schindelin
2007-03-22 23:23 ` Rob Landley
2007-03-22 23:27 ` Paul Brook
2007-03-22 23:57 ` Julian Seward
2007-03-23 0:35 ` Paul Brook
2007-03-23 0:37 ` Johannes Schindelin
2007-03-22 23:29 ` Thiemo Seufer
2007-03-22 23:45 ` Rob Landley
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=45F94E97.10502@codemonkey.ws \
--to=anthony@codemonkey.ws \
--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).