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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list