On 04/26/2012 12:39 PM, Cole Robinson wrote: 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. Seems like a nice idea; it will be interesting to see who else picks up on it. -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

On 04/26/2012 03:12 PM, Eric Blake wrote: 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 :-) 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 02:39:14PM -0400, Cole Robinson wrote: 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 Thu, Apr 26, 2012 at 02:39:14PM -0400, Cole Robinson wrote: 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