Stable branch releases?
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.
Regards,
Anthony Liguori
Quoted 3 lines · Anthony Liguori
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. One question is what to call these releases, though.
I'd like to keep the kernel part synced with 2.6.x.y for as long as that's maintained. Perhaps we can call these releases kvm-stable-x.y (though it would cause confusion with kvm-xx). 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.
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Quoted 6 lines · Avi Kivity
Quoted 3 lines · Anthony Liguori
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?
Quoted 1 line
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.
Quoted 1 line
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?
Quoted 1 line
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.
Quoted 2 lines
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.
Regards,
Anthony Liguori
Quoted 17 lines · Anthony Liguori
Quoted 11 lines · Avi Kivity
Quoted 7 lines · Anthony Liguori
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?
Quoted 7 lines
Quoted 1 line
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.
As we're getting close to kvm-xxx anyway, maybe we could forget this number scheme, and adopt something that tracks linux. This way, you know exactly what kernel a released is based on. Something in the lines of kvm-29.1 for updates to the .29 series, (of course _this_ scheme is bad, because it brings clashes)
Signature · 5 lines
Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."
Quoted 6 lines · Glauber Costa
As we're getting close to kvm-xxx anyway, maybe we could forget this number scheme, and adopt something that tracks linux. This way, you know exactly what kernel a released is based on. Something in the lines of kvm-29.1 for updates to the .29 series, (of course _this_ scheme is bad, because it brings clashes)
It also ignores qemu, which is larger contributor to user visible features...
Maybe stable releases should have separate packages for kvm and qemu: kvm-modules-2.6.29.1 and qemu-kvm-0.9.1.17. Users would pick the latest of each, and would only need to upgrade a component that's changed.
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Quoted 11 lines · Avi Kivity
Quoted 6 lines · Glauber Costa
As we're getting close to kvm-xxx anyway, maybe we could forget this number scheme, and adopt something that tracks linux. This way, you know exactly what kernel a released is based on. Something in the lines of kvm-29.1 for updates to the .29 series, (of course _this_ scheme is bad, because it brings clashes)
It also ignores qemu, which is larger contributor to user visible features...
Maybe stable releases should have separate packages for kvm and qemu: kvm-modules-2.6.29.1 and qemu-kvm-0.9.1.17. Users would pick the latest of each, and would only need to upgrade a component that's changed.
Yes, this would be IMHO the best overall solution. Can we take kvm-userspace maint/2.6.29 and call it qemu-kvm-0.9.1-1? Most users don't need newer kernel modules if they have a relatively recent distro.
Regards,
Anthony Liguori
Quoted 3 lines · Anthony Liguori
Yes, this would be IMHO the best overall solution. Can we take kvm-userspace maint/2.6.29 and call it qemu-kvm-0.9.1-1? Most users don't need newer kernel modules if they have a relatively recent distro.
Right, that's another advantage of split repos.
I wonder about splitting the ordinary kvm-xx releases? It means doubling the download/build/install cycle, but it will increase similarity to the stable releases.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 8 lines · Avi Kivity
Quoted 3 lines · Anthony Liguori
Yes, this would be IMHO the best overall solution. Can we take kvm-userspace maint/2.6.29 and call it qemu-kvm-0.9.1-1? Most users don't need newer kernel modules if they have a relatively recent distro.
Right, that's another advantage of split repos.
I wonder about splitting the ordinary kvm-xx releases? It means doubling the download/build/install cycle, but it will increase similarity to the stable releases.
I was going to suggest that to but then wanted to avoid complicating things. I think it's the right model.
Regards,
Anthony Liguori
Quoted 4 lines · Anthony Liguori
Quoted 2 lines
I wonder about splitting the ordinary kvm-xx releases? It means doubling the download/build/install cycle, but it will increase similarity to the stable releases.
I was going to suggest that to but then wanted to avoid complicating things. I think it's the right model.
I have to get the package/build machinery to do that anyway.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 9 lines · Anthony Liguori
Quoted 8 lines · Avi Kivity
Quoted 6 lines · Glauber Costa
As we're getting close to kvm-xxx anyway, maybe we could forget this number scheme, and adopt something that tracks linux. This way, you know exactly what kernel a released is based on. Something in the lines of kvm-29.1 for updates to the .29 series, (of course _this_ scheme is bad, because it brings clashes)
Quoted 6 lines
Quoted 3 lines
It also ignores qemu, which is larger contributor to user visible features...
Maybe stable releases should have separate packages for kvm and qemu: kvm-modules-2.6.29.1 and qemu-kvm-0.9.1.17. Users would pick the latest of each, and would only need to upgrade a component that's changed.
Yes, this would be IMHO the best overall solution. Can we take kvm-userspace maint/2.6.29 and call it qemu-kvm-0.9.1-1? Most users don't need newer kernel modules if they have a relatively recent distro.
There's a slight snag here. The kernel module wants bits from the userspace package (the backward compatibility kit and makefiles); the userspace package wants some kernel bits (header files).
I think we can work around it by using 'git symbolic-ref'. kvm.git would have a maint/2.6.29 branch, which would have an alias called maint/0.9.1. Similarly, kvm-userspace.git would have a branch called maint/0.9.1, with an alias called maint/2.6.29. Commits into one would automatically appear on the other.
This sound reasonable?
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 9 lines · Avi Kivity
Quoted 2 lines · Anthony Liguori
Yes, this would be IMHO the best overall solution. Can we take kvm-userspace maint/2.6.29 and call it qemu-kvm-0.9.1-1? Most users don't need newer kernel modules if they have a relatively recent distro.
There's a slight snag here. The kernel module wants bits from the userspace package (the backward compatibility kit and makefiles); the userspace package wants some kernel bits (header files).
I think we can work around it by using 'git symbolic-ref'. kvm.git would have a maint/2.6.29 branch, which would have an alias called maint/0.9.1. Similarly, kvm-userspace.git would have a branch called maint/0.9.1, with an alias called maint/2.6.29. Commits into one would automatically appear on the other.
This sound reasonable?
That's close to sounding like git-giberish to me but if you think it'll do what you want it to do then it works for me :-)
In terms of actual releases, I'd really like to see a kvm-0.10.0-0 release based on the qemu-0.10.0 release that didn't contain any kernel modules. Ideally, we would move libkvm into the qemu tree and collapse the tree too so it looked very much like qemu does today.
Regards,
Anthony Liguori
Quoted 5 lines · Anthony Liguori
Quoted 4 lines · Avi Kivity
Quoted 2 lines · Anthony Liguori
Yes, this would be IMHO the best overall solution. Can we take kvm-userspace maint/2.6.29 and call it qemu-kvm-0.9.1-1? Most users don't need newer kernel modules if they have a relatively recent distro.
Quoted 7 lines
Quoted 5 lines
There's a slight snag here. The kernel module wants bits from the userspace package (the backward compatibility kit and makefiles); the userspace package wants some kernel bits (header files).
I think we can work around it by using 'git symbolic-ref'. kvm.git would have a maint/2.6.29 branch, which would have an alias called maint/0.9.1. Similarly, kvm-userspace.git would have a branch called maint/0.9.1, with an alias called maint/2.6.29. Commits into one would automatically appear on the other.
This sound reasonable?
That's close to sounding like git-giberish to me but if you think it'll do what you want it to do then it works for me :-)
I was hoping someone (=you) would verify that it means what I think it means.
Quoted 1 line
In terms of actual releases, I'd really like to see a kvm-0.10.0-0 release based on the qemu-0.10.0 release that didn't contain any kernel modules.
Pretty soon I'll fork maint/2.6.30, that's a good time for forking kvm-userspace.git. I could fork at the point qemu-0.10.0 was released.
Unfortunately, the last qemu merge pulled in post-0.10.0 bits. I guess I could back them out. It isn't going to be pretty.
Quoted 1 line
Ideally, we would move libkvm into the qemu tree and collapse the tree too so it looked very much like qemu does today.
I have a script that takes qemu-userspace.git and rewrites it to multiple repositories (one per subdirectory, basically, plus one top-level). That allows us to keep the bios, testsuite, external module compat kit, etc.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 2 lines · Avi Kivity
I was hoping someone (=you) would verify that it means what I think it means.
I'm the wrong person to ask :-/
Quoted 5 lines
Quoted 1 line
In terms of actual releases, I'd really like to see a kvm-0.10.0-0 release based on the qemu-0.10.0 release that didn't contain any kernel modules.
Pretty soon I'll fork maint/2.6.30, that's a good time for forking kvm-userspace.git. I could fork at the point qemu-0.10.0 was released.
Unfortunately, the last qemu merge pulled in post-0.10.0 bits. I guess I could back them out. It isn't going to be pretty.
From a stable maintenance point-of-view, having the kvm stable tree based on stable_0_10 will make your life a lot easier since you only have to worry about tracking kvm-specific stable fixes.
Fixing up the tree now will be painful. You could either merge back the older tree or revert changes in the QEMU tree until you get to release_0_10_0. Then merging against stable_0_10 would be pretty easy. None of it is very bisect friendly though :-/
Quoted 3 lines
Quoted 1 line
Ideally, we would move libkvm into the qemu tree and collapse the tree too so it looked very much like qemu does today.
I have a script that takes qemu-userspace.git and rewrites it to multiple repositories (one per subdirectory, basically, plus one top-level). That allows us to keep the bios, testsuite, external module compat kit, etc.
Great. I know you dislike it conceptually, but it's worth considering splitting out the KVM bios changes into patches as part of the patch queue that's in qemu SVN. It can potentially help the distros manage the KVM and QEMU bios builds in the same mechanism.
What do you plan to do about non-stable KVM releases?
Regards,
Anthony Liguori
Quoted 10 lines · Anthony Liguori
Quoted 6 lines · Avi Kivity
Quoted 3 lines · Anthony Liguori
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.
Quoted 3 lines
Quoted 1 line
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-?)??
Quoted 4 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
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).
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.