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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to