Re: [libvirt] libvirt stable releases
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