1:58 a.m.
On Wed, May 13, 2015 at 03:31:09PM +0000, Serge Hallyn wrote:
Quoting Guido Günther (agx(a)sigxcpu.org):
> On Tue, May 12, 2015 at 11:14:09AM +0200, Martin Kletzander wrote:
> > On Tue, May 12, 2015 at 05:27:34PM +1000, Tony Breeds wrote:
> > >On Mon, May 11, 2015 at 01:14:58PM +0200, Martin Kletzander wrote:
> > >
> > >>Determining this by version might not be reliable, but more
> > >>importantly working around bug in underlying software is something
> > >>that shouldn't be done at all IMHO. Let the maintainers backport
> > >>whatever needs to be done.
> > >
> > >I agree with you in an ideal world but there are times when we do need
> > >to add work arounds in $project_x to work around issues in $project_y.
> > >
> > >>>Ther nova side will be pretty easy regardless.
> > >>>
> > >>>I'd say the best solution would be to back port the
'fix' but that seems like a
> > >>>lot of effort given the number of distros and libvirt versions
potentiall
> > >>>involved.
> > >>>
> > >>
> > >>If you want the fix to be distro-agnostic, there's nothing easier
than
> > >>back-porting the fix into our upstream maintenance branches. Those
> > >>should make the life of distro maintainers easy (although it looks
> > >>like not many distros use it).
> > >
> > >And this is part of the problem. If I understand correctly Ubuntu
cloud-archive
> > >is using libvirt 1.2.12 which is *NOT* a maintenance release so that leaves
us
> > >with doing an additional backport to 1.2.12 and getting the cloud-archive
team
> > >to take it[1] or Adding a hack to nova. And that's just Ubuntu
It's hard to
> > >say for sure that some vendor isn't running libvirt 1.2.12 also.
> > >
> > >>Having said that I'm not sure which commit(s) are those that need
to
> > >>be back-ported. Having known your libvirt version, it shouldn't be
> > >>too hard looking for the differences and finding the right commit.
> > >>When back-porting request is made on the list, it is usually acted
> > >>upon. If you can't find the exact commit, let me know and I'll
do my
> > >>best to help.
> > >
> > >So a git bisect points at:
> > >---
> > >commit a103bb105c0c189c3973311ff1826972b5bc6ad6
> > >Author: Daniel P. Berrange <berrange(a)redhat.com>
> > >Date: Tue Feb 10 15:59:57 2015 +0000
> > >
> > > qemu: fix setting of VM CPU affinity with TCG
> > >---
> > >
> > >A small amount of reading implies to me that we'd be looking at
backporting
> > >a103bb105c0c189c3973311ff1826972b5bc6ad6 to any maintenance branch that
contains
> > >b07f3d821dfb11a118ee75ea275fd6ab737d9500. Which I think is 1.2.13 only, but
I
> > >could be wrong.
> > >
> >
> > 1.2.13 has the commit already in the release and 1.2.12-maint has it
> > as a first back-port right after release. The problem is that there
> > was no maintenance release of 1.2.12 yet. Maybe they would use
> > 1.2.12.1 if it existed.
> >
> > I Cc'd Guido as an upstream debian maintainer, maybe he'll have some
> > insights. @Guido: would it help if we created a maintenance release
> > from the v1.2.12-maint branch? Or is the only thing missing the fact
> > that the launchpad bug is not moved to libvirt?
Thanks guys, I'm going to cherrypick that patch into vivid right now. (It
should be in wily as that is 1.2.15).
> Basically Ubuntu takes the version that is in Debian testing, unstable
> or experimental at time of their release and adds pathes. There's little
> to no sync unfortunately (except for the awesome efforts to sync the
> apparmor stuff)
>
> Debian itself is not using 1.2.12 anywhere. Current stable has 1.2.9 +
> maintenance patches (which I intend to switch over to the maintenance
> releases soonish and support hopefully Cole with these), oldstable has
> 0.9.12.3 and unstable/sid has 1.2.15 (and will keep following the
> releases).
>
> I've added Serge since he might to jump onto 1.2.12.1 maintenance
> relasese.
If you mean contributing by adding patches that we add to vivid, I'm
definately willing to do that. Note that vivid has a pretty short
lifecycle so it wouldn't go on for very long. If people are willing
to tag patches with '[1.2.12.1-maint]' on this list I'm willing to
support this longer.
Rather than tagging patches with -maint, we just back-port them
straight into the maintenance branch. If there are more distributions
using the maintenance branch or would be if there was more review,
etc., I'm sure we could come up with some solution to suit everyone
(or majority at least).
After patches are back-ported, Cole does a maintenance release which
should make it even more easier (e.g. you don't want to follow up the
list or the git repo) since the release announcement goes to
libvirt-announce as with other releases.
However, I'm not sure when Cole does those releases (if it's time-,
commit- or random-based). Anyway, as I said earlier, we should
definitely come up with how to do this so it helps other maintainers
out there. I'm offering my help.
> I'm happy about any additional notifications for things that
should go
> into distributions.
>
> Cheers,
> -- Guido
>
Thanks!
-serge