On Fri, Oct 18, 2013 at 11:30:48AM -0400, Sean Dague 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. > > > > 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. > > > > 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. > > Most of this has already been addressed in the thread. There is a huge > trade of here, freezing requirements in the short term makes everything > work, in the long term, it causes huge pain. Just look at SQLA pin at <= > 0.7.99, which has gone far too long without getting resolved, and has > all the distros carrying patches to work around it (now why none of them > have contributed those back.... is another question). > > Getting to a single global requirements list this summer took 3 weeks of > cross team coordination, because of pinning. Having to unwind > coordinated patches like that is lots of fun, let me tell you. :) And > while the result isn't perfect, it's so much better than the random gate > wedges we were regularly getting that were actually unsolvable through > normal process fixes. > > If you are a project with tempest integration, then you actually get a > code voice in global requirements bumps, because a g-r change can't land > without passing tempest / devstack tests. So integrated projects take > note, there are lots of reasons you want to have good tempest tests, and > protecting yourself from requirements changes is one of those (wouldn't > help in the tuscar case, as that's only got unit tests). > > So, I think we largely need to just take our lumps realizing that we > don't have tight control over the python world, and it's better to react > quickly, then to hide behind a pin, and not realize that we're massively > broken with the latest versions of libraries out there. > > That being said, because WSME is in stackforge, I think we could > actually do better than just take our lumps. But I think that's for > discussing at the requirements session at summit. > > -Sean > > -- > Sean Dague > http://dague.net > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Thank you all for responses as these helped me to understand this topic more. I am glad I now know about strugle with frozen deps w/r/t packaging to distros. -- Petr Blaho, pbl...@redhat.com Software Engineer _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev