[libvirt] libvirt stable releases
Hi all, An idea we've kicked around for awhile in Red Hat/Fedora land is doing official libvirt stable releases, but nothing ever took shape. The idea was brought up again recently and I've offered to help get something going. I've pushed an upstream v0.9.11-maint branch with a bunch of patches cherry-picked to libvirt 0.9.11. Shortly I'll be cutting a 0.9.11.1 and pushing it to the website, like other releases. Why 0.9.11? Because that's what we will be shipping in Fedora 17 :) Typically our policy with fedora is to stick with one libvirt version for the length of a release. Cutting stable releases should save us from having to backport patches, and hopefully get us more bug fixes than backporting only what our users report. So I don't plan on doing a similar branch for 0.9.12 or 0.9.13, but will probably do a branch in 6 months time for whatever libvirt version we are shipping in Fedora 18. While my primary motiviation at the moment is making Fedora maintenance easier, I hope that other distros will use the stable releases as well, where we can all benefit from each others QA and attention. Any feedback appreciated! Thanks, Cole
On 04/26/2012 12:39 PM, Cole Robinson wrote:
Hi all,
An idea we've kicked around for awhile in Red Hat/Fedora land is doing official libvirt stable releases, but nothing ever took shape. The idea was brought up again recently and I've offered to help get something going.
I've pushed an upstream v0.9.11-maint branch with a bunch of patches cherry-picked to libvirt 0.9.11. Shortly I'll be cutting a 0.9.11.1 and pushing it to the website, like other releases.
How often do you plan to cut releases on the current maint branch? Once a month or so? What's the preferred method for marking a patch as a candidate for inclusion on the branch? Right now, it looks like we are using cherry-pick -x to populate the branch; maybe someday it would be worth swapping over to the style used by the kernel where you base candidate patches directly off the stable branch, then merge the branch into master for development, so that master is always a superset of all commits in stable; but that implies using a merge paradigm whereas our current style is that mainline is linear history. Food for thought, but certainly not anything worth changing right away until we have more experience with how popular the stable branch turns out to be.
Why 0.9.11? Because that's what we will be shipping in Fedora 17 :) Typically our policy with fedora is to stick with one libvirt version for the length of a release. Cutting stable releases should save us from having to backport patches, and hopefully get us more bug fixes than backporting only what our users report. So I don't plan on doing a similar branch for 0.9.12 or 0.9.13, but will probably do a branch in 6 months time for whatever libvirt version we are shipping in Fedora 18.
While my primary motiviation at the moment is making Fedora maintenance easier, I hope that other distros will use the stable releases as well, where we can all benefit from each others QA and attention.
Any feedback appreciated!
Seems like a nice idea; it will be interesting to see who else picks up on it. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 04/26/2012 03:12 PM, Eric Blake wrote:
On 04/26/2012 12:39 PM, Cole Robinson wrote:
Hi all,
An idea we've kicked around for awhile in Red Hat/Fedora land is doing official libvirt stable releases, but nothing ever took shape. The idea was brought up again recently and I've offered to help get something going.
I've pushed an upstream v0.9.11-maint branch with a bunch of patches cherry-picked to libvirt 0.9.11. Shortly I'll be cutting a 0.9.11.1 and pushing it to the website, like other releases.
How often do you plan to cut releases on the current maint branch? Once a month or so?
For now I figured I'd just wing it. I want to at least every 2 weeks look over master commits for suitable backports, and then just judge from there. Not sure it's worth the effort to cut regular releases if no compelling bug fixes are accumulating.
What's the preferred method for marking a patch as a candidate for inclusion on the branch?
I figured for now I could just scrape the commits manually. If I'm missing things or being overly patch happy maybe we can figure out some process, but at this point it seems overkill. But if there's a bug fix that people think it's worth accelerating a stable release for, just CC me and comment to that effect.
Right now, it looks like we are using cherry-pick -x to populate the branch; maybe someday it would be worth swapping over to the style used by the kernel where you base candidate patches directly off the stable branch, then merge the branch into master for development, so that master is always a superset of all commits in stable; but that implies using a merge paradigm whereas our current style is that mainline is linear history. Food for thought, but certainly not anything worth changing right away until we have more experience with how popular the stable branch turns out to be.
Yeah one of my main goals at the start is making the process as simple as possible and have near zero impact on current libvirt git and release processes. Agreed that seeing how it turns out might necessitate more process but we'll just have to see. - Cole
On 04/26/2012 03:12 PM, Eric Blake wrote:
On 04/26/2012 12:39 PM, Cole Robinson wrote:
Hi all,
An idea we've kicked around for awhile in Red Hat/Fedora land is doing official libvirt stable releases, but nothing ever took shape. The idea was brought up again recently and I've offered to help get something going.
I've pushed an upstream v0.9.11-maint branch with a bunch of patches cherry-picked to libvirt 0.9.11. Shortly I'll be cutting a 0.9.11.1 and pushing it to the website, like other releases. How often do you plan to cut releases on the current maint branch? Once a month or so?
What's the preferred method for marking a patch as a candidate for inclusion on the branch?
The Fedora-specific method we've used lately of having a bugzilla record that includes the upstream commit ID and is marked as POST seems to work well, but doesn't directly apply here, because the upstream bugzilla component doesn't have multiple releases to select from in the BZ entries, and anyway it seems like a lot of extra bookkeeping. It would of course be simplest for people to just directly cherry-pick what they wanted into the branch, but that's sure to lead to patch bloat on the stable branches. Maybe each stable release could have a "-maint-candidate" branch that anyone is allowed to cherry-pick into, and a designated person could periodically go through and pick from there into the -maint branch (Nah, that could possibly lead to 2 rounds of merge conflict resolution, which doesn't help anybody, and could lead to new bugs being introduced by botched merges). How about just an email to the list with a particular subject (e.g. "[libvirt 0.9.11-maint pull request] commit id nnnnnn") with the body having the reason for wanting the patch pulled into the maint release; these emails would be serviced by some smaller group of people (or maybe one designated person per release). Just random ideas - I have no practical experience with any of these setups, so they may all be equally flawed :-)
Right now, it looks like we are using cherry-pick -x to populate the branch; maybe someday it would be worth swapping over to the style used by the kernel where you base candidate patches directly off the stable branch, then merge the branch into master for development, so that master is always a superset of all commits in stable; but that implies using a merge paradigm whereas our current style is that mainline is linear history. Food for thought, but certainly not anything worth changing right away until we have more experience with how popular the stable branch turns out to be.
I guess my problem with doing it that way (stable branch first, then merge to master) is that you can never go back after the fact and decide that something put into master really should also be added to a maintenance release. And it seems to me like the majority of fixes on branches would be of that nature.
On Thu, Apr 26, 2012 at 01:12:58PM -0600, Eric Blake wrote:
On 04/26/2012 12:39 PM, Cole Robinson wrote:
Hi all,
An idea we've kicked around for awhile in Red Hat/Fedora land is doing official libvirt stable releases, but nothing ever took shape. The idea was brought up again recently and I've offered to help get something going.
I've pushed an upstream v0.9.11-maint branch with a bunch of patches cherry-picked to libvirt 0.9.11. Shortly I'll be cutting a 0.9.11.1 and pushing it to the website, like other releases.
How often do you plan to cut releases on the current maint branch? Once a month or so?
What's the preferred method for marking a patch as a candidate for inclusion on the branch?
Right now, it looks like we are using cherry-pick -x to populate the branch; maybe someday it would be worth swapping over to the style used by the kernel where you base candidate patches directly off the stable branch, then merge the branch into master for development, so that master is always a superset of all commits in stable; but that implies using a merge paradigm whereas our current style is that mainline is linear history. Food for thought, but certainly not anything worth changing right away until we have more experience with how popular the stable branch turns out to be.
One reason why the kernel does that is that their master can be quite a fast changing place & potentially unstable, so hard to track when you are doing development. Conceptually though I don't really like that because of the non-linearity of history and the horrificness of merge commits[1]. In any case I think our 'master' branch is stable enough that it does not cause too many problems for people developing new patches. Daniel [1] My dislike of merge commits has grown tremendously having worked on OpenStack now. Navigating history & tracking down regressions is so much more unpleasant with merges. -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, Apr 26, 2012 at 02:39:14PM -0400, Cole Robinson wrote:
Hi all,
An idea we've kicked around for awhile in Red Hat/Fedora land is doing official libvirt stable releases, but nothing ever took shape. The idea was brought up again recently and I've offered to help get something going.
I've pushed an upstream v0.9.11-maint branch with a bunch of patches cherry-picked to libvirt 0.9.11. Shortly I'll be cutting a 0.9.11.1 and pushing it to the website, like other releases.
BTW, I think you forgot to push the tags for that branch - there's no tag for v0.9.11.1 or v0.9.11.2 in GIT history Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 04/27/2012 04:18 AM, Daniel P. Berrange wrote:
On Thu, Apr 26, 2012 at 02:39:14PM -0400, Cole Robinson wrote:
Hi all,
An idea we've kicked around for awhile in Red Hat/Fedora land is doing official libvirt stable releases, but nothing ever took shape. The idea was brought up again recently and I've offered to help get something going.
I've pushed an upstream v0.9.11-maint branch with a bunch of patches cherry-picked to libvirt 0.9.11. Shortly I'll be cutting a 0.9.11.1 and pushing it to the website, like other releases.
BTW, I think you forgot to push the tags for that branch - there's no tag for v0.9.11.1 or v0.9.11.2 in GIT history
Tags pushed now. Thanks, Cole
On Thu, Apr 26, 2012 at 02:39:14PM -0400, Cole Robinson wrote:
Hi all,
An idea we've kicked around for awhile in Red Hat/Fedora land is doing official libvirt stable releases, but nothing ever took shape. The idea was brought up again recently and I've offered to help get something going.
I've pushed an upstream v0.9.11-maint branch with a bunch of patches cherry-picked to libvirt 0.9.11. Shortly I'll be cutting a 0.9.11.1 and pushing it to the website, like other releases.
That's very much appreciated and I will certainly track those branches for Debian in case it matches our release pattern and let you know about any additionaly patches I'll cherry-pick from master. Cheers, -- Guido
Why 0.9.11? Because that's what we will be shipping in Fedora 17 :) Typically our policy with fedora is to stick with one libvirt version for the length of a release. Cutting stable releases should save us from having to backport patches, and hopefully get us more bug fixes than backporting only what our users report. So I don't plan on doing a similar branch for 0.9.12 or 0.9.13, but will probably do a branch in 6 months time for whatever libvirt version we are shipping in Fedora 18.
While my primary motiviation at the moment is making Fedora maintenance easier, I hope that other distros will use the stable releases as well, where we can all benefit from each others QA and attention.
Any feedback appreciated!
Thanks, Cole
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
participants (5)
-
Cole Robinson -
Daniel P. Berrange -
Eric Blake -
Guido Günther -
Laine Stump