Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
Hi Avi,
Since a number of people are using the maint/2.6.29 branch, perhaps
we could start doing releases from it? For instance, a kvm-74.1,
kvm-74.2, etc. set of releases. Likewise, when we start
maint/2.6.30, a new set of stable releases could follow.
Yes, I want to do that.
Ok, is there anything standing in the way of doing this? What would
prevent us from doing a stable release in the next few days even? Is
there anything we can do to help?
Nothing, really. There used to be the lack of a test suite but that's
no longer the case.
One question is what to call these releases, though.
I'd like to see it be named kvm-XX.y or something like that to keep a
close association between what the base release was. For instance,
you wouldn't expect HPET support in kvm-74.3 but you may expect it if
it were kvm-stable-3 or something.
Won't work - the kernel versions don't correspond to any kvm-xx
release. Once a new release cycle is imminent, I only apply bugfixes to
the tree that eventually goes into -rc1, and of course later updates are
fixes only so it doesn't correspond to any kvm-xx release..
The kvm.git and kvm-userspace.git trees are really staging areas and I'd
like to de-emphasise them if favor of the Linux and qemu trees. Maybe,
once qemu starts making regular releases, we can name a combined
kvm/qemu release after both trees (kvm-0.10.0/2.6.29-?)??
I'd like to keep the kernel part synced with 2.6.x.y for as long as
that's maintained.
How do you deal with maint/2.6.29 right now in the kvm.git tree? Do
you sync that with the 2.6.x.y releases?
Yes. As long as 2.6.29 is unreleased, maint/2.6.29 is Linus' tree. Any
fixes to maint/2.6.29 only go in by way of Linus. Once 2.6.29 is
released, maint/2.6.29 is synced to -stable (and commits only go in by
way of -stable). Once 2.6.29.y is abandoned, I'm free to commit on my own.
Perhaps we can call these releases kvm-stable-x.y (though it would
cause confusion with kvm-xx).
If you're just suggesting introducing -stable, it really doesn't
matter to me. I don't think it's necessary FWIW.
The problem is that x.y won't be a derivative of x, if x is a kvm-xx
release. It's not just a string prefix.
So, users of kvm-stable-x.y would be running the same code as users
running Linux-2.6.x.y with the bundled kvm modules.
I think the majority of utility in the release numbers are associated
with the userspace bits (maybe I'm a bit bias :-)). I don't think
most users care about the differences between 2.6.28 and 2.6.29 kernel
bits, but the different between kvm-74 and kvm-83 is very important
feature wise.
So maybe we should name the release after the qemu version, or changeseg
number, or snapshot date. I agree that most features come from qemu
(and many kernel features depend on the actual host kernel, not just
what kernel the modules were taken from).
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
