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