Re: libvirt stable releases

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]