Open Stack

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.

> 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. We do from time to time
when we find a project that becomes known for regularly breaking its
contract.

> 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...
> 
> 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 :-)
> 
> 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.

Freezing a dep version and regularly upgrading it means freezing it in
24-ish repos and then upgrading it in 24-ish repos. Doing it across the
board as a general rule would quickly become unworkable.

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

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

Monty