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?
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.