Open Stack

On 10/17/2013 09:21 PM, Monty Taylor wrote:
> 
> 
> On 10/17/2013 08:12 AM, Petr Blaho wrote:
>> Hi all,
>>
>> this is probably 3rd or 4th time in quite short time when we were bitten
>> by new version of some out dependencies.
>>
>> Last one (https://review.openstack.org/#/c/52327/3) was about WSME
>> released version 0.5b6 and our tests fail.
> 
> Well - I think we should probably not be depending on any beta versions
> of anything that aren't part of our gate. So there's issue number 1.

Agreed, though as I wrote in another thread, WSME 0.5b6 fixed this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725652

so it really was needed to upgrade (at least in Debian). Plus Ceilometer
needs it. Probably the problem is that it should have been a less
intrusive change (I don't know the specific issue here, sorry).

>> I do not want to argue if problem is on tuskar side (probably tuskar is
>> to blame according to what jistr found out) or WSME but I think
>> we should discuss possibility of freezing versions in our dependencies
>> definitions and once in a time check for new versions of deps and do
>> update as a separate task.
> 
> We don't really like pinning arbitrarily like that because it can cause
> inter-project issues and stress on packagers.

I second this (to the exception that we are called "package
maintainers", but hey, I'm getting used to that... :) ).

Also, "pinning" to a specific version doesn't make an issue go away. It
only hides it, and hits package maintainers hardly, with upstream saying
"but hey, the version is pinned, what are you talking about?", when the
package already reached the distribution (and cannot be downgraded).

So please do not ask to hide problems by restricting pinning...

> We do from time to time
> when we find a project that becomes known for regularly breaking its
> contract.

Which is: when a project has a big bug (which should be corrected in the
upstream dependency/package, and in which case only a != relation is
needed) or when the API breaks. Though that shouldn't be a reason to
ignore the given problem if it can be addressed and try to fix.

>> Current state of having open version constraints like WSME<=0.5b5 leads
>> to occasional (or as I see quite frequent) jenkins job failures (as jenkins
>> use clean venv for instalation - devs can have older one so they can
>> miss failure with new version of dep) and these "sudden" failures force
>> us to investigate and divert from planned tasks etc...

This is *exactly* what we want: that you investigate when there's a
problem, and that you fix quickly. Again, please don't complain, and eat
your vegetables, even if you don't like it (you are right, they have a
bad taste, but we can't fix that...)! :)

>> I think that having regular "update deps" task can lead to better time
>> management and having less "sudden" jenkins failures will be benefical
>> to developers' health :-)

And a very, very big nightmare for downstream distributions. Please,
let's not do that.

>> Please, tell me if I am missing some obvious problem with freezing dep
>> versions and/or regular update task and if I miss a good side of these
>> "sudden version strikes" too.

See above. Also, remember that package maintainers are a few (me alone
for Debian, maybe 5 people in Ubuntu/Canonical) fighting hundreds of
developers who wish not to be disturbed. However, in this particular
case, the majority isn't always right. ;)

*I* do not control all of the version of Python modules that gets into
Debian (I'm not sure if I should add "luckily" or "unfortunately" ...).

> However, in this particular case, I believe you're pointing out a
> behvior we're doing with WSME that we should, well, not do.

If WSME should be fixed, let's fix WSME. However, Ceilometer requires
0.5b6, so we got to move forward.

> We'll also be having a requirements session at the summit to talk about
> next steps for requirements processing - hopefully you can make it!

I'll make sure to not miss that one.

Cheers,

Thomas Goirand (zigo)