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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
