Open Stack

On Thu, Jul 17, 2014, Russell Bryant <rbryant at redhat.com> wrote:
> On 07/17/2014 02:31 PM, Johannes Erdfelt wrote:
> > It kind of helps. It's still implicit in that you need to look at what
> > features are enabled at what version and determine if it is being
> > tested.
> > 
> > But the behavior is still broken since code is still getting merged that
> > isn't tested. Saying that is by design doesn't help the fact that
> > potentially broken code exists.
> 
> Well, it may not be tested in our CI yet, but that doesn't mean it's not
> tested some other way, at least.

I'm skeptical. Unless it's tested continuously, it'll likely break at
some time.

We seem to be selectively choosing the continuous part of CI. I'd
understand if it was reluctantly because of immediate problems but
this reads like it's acceptable long-term too.

> I think there are some good ideas in other parts of this thread to look
> at how we can more reguarly rev libvirt in the gate to mitigate this.
> 
> There's also been work going on to get Fedora enabled in the gate, which
> is a distro that regularly carries a much more recent version of libvirt
> (among other things), so that's another angle that may help.

That's an improvement, but I'm still not sure I understand what the
workflow will be for developers.

Do they need to now wait for Fedora to ship a new version of libvirt?
Fedora is likely to help the problem because of how quickly it generally
ships new packages and their release schedule but it would still hold
back some features?

> > Also, this explanation doesn't answer my question about what happens
> > when the gate finally gets around to actually testing those potentially
> > broken code paths.
> 
> I think we would just test out the bump and make sure it's working fine
> before it's enabled for every job.  That would keep potential breakage
> localized to people working on debugging/fixing it until it's ready to go.

The downside is that new features for libvirt could be held back by
needing to fix other unrelated features. This is certainly not a bigger
problem than users potentially running untested code simply because they
are on a newer version of libvirt.

I understand we have an immediate problem and I see the short-term value
in the libvirt version cap.

I try to look at the long-term and unless it's clear to me that a
solution is proposed to be short-term and there are some understood
trade-offs then I'll question the long-term implications of it.

JE