Re: Stable branch releases?
Anthony Liguori wrote: Avi Kivity wrote: Glauber Costa wrote: 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. 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? -- error compiling committee.c: too many arguments to function -- 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
Re: Stable branch releases?
Avi Kivity wrote: Anthony Liguori wrote: 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 -- 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
Re: Stable branch releases?
Anthony Liguori wrote: Avi Kivity wrote: Anthony Liguori wrote: 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 :-) I was hoping someone (=you) would verify that it means what I think it means. 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. 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. -- error compiling committee.c: too many arguments to function -- 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
Re: Stable branch releases?
Avi Kivity wrote: I was hoping someone (=you) would verify that it means what I think it means. I'm the wrong person to ask :-/ 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 :-/ 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 -- 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
Re: Stable branch releases?
Anthony Liguori wrote: 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. -- error compiling committee.c: too many arguments to function -- 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
Re: Stable branch releases?
Avi Kivity wrote: Anthony Liguori wrote: 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 -- 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
Re: Stable branch releases?
Anthony Liguori wrote: 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. -- error compiling committee.c: too many arguments to function -- 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
Re: Stable branch releases?
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. 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. -- 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
Re: Stable branch releases?
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? 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. 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? 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. 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 -- 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
Re: Stable branch releases?
On Mon, Feb 9, 2009 at 5:39 PM, Anthony Liguori aligu...@us.ibm.com 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? 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) -- Glauber Costa. Free as in Freedom http://glommer.net The less confident you are, the more serious you have to act. -- 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
Re: Stable branch releases?
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
Re: Stable branch releases?
Glauber Costa wrote: 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. -- 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
Re: Stable branch releases?
Avi Kivity wrote: Glauber Costa wrote: 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 -- 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
