On 10/18/2013 03:35 AM, Clint Byrum wrote: > Excerpts from Thomas Goirand's message of 2013-10-17 08:33:44 -0700: >> 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. ;) >> > > It makes me sad that you feel this is a fight.
Wooops. This has been written very late, just right at the end of the release cycle. Like TTX wrote on IRC just after the release, I'm going to sleep the next 48 hours! :) I certainly wouldn't want anyone to feel sad. The OpenStack developer community has been awesome, and I enjoy a lot interacting with everyone. > We (developers of OpenStack) want users to find and use OpenStack. You > are one of the many channels by which they do that. So please, it is not > a fight, it is a dialog between peers. Right. What I wanted to write was that maintaining the dependencies of OpenStack in Sid makes me feel like "fire fighting". (This summer I really had this feeling.) Objectives, sometimes, run in opposition with what *feels apparently* logic for upstream OpenStack, like putting a version cap on the upper bound of a Python module. This may feel that this fixes the gate. While this may be right temporarily (as a given patch may work, and the gate tests will pass), this only delays the trouble. Adding a new dependency in upstream OpenStack is just adding a line in requirements.txt, and this feels this has very little consequences upstream or in the gate. For downstream, distributions, that's a lot of work, and newer versions as well. What made me wrote the above is that it feels frustrating and disappointing to always read that we should put upper caps on versions of OpenStack dependencies, and that it will solve problems. For downstream, we should do the opposite way or we *get into* troubles. In this regard, distributions are alone trying to spread the word, and at least I am having a hard time doing it. (that's for the feeling of being isolated that I have) For example, the troubles with SQLAlchemy 0.8.2 has been a reoccurring topic for the past 3 months, and I am puzzled to find a way to let everyone understand, so that we don't run into infinite loops on the topic. I could for example read this from yesterday, when telling about https://bugs.launchpad.net/nova/+bug/1241038: > Global requirements still lists > SQLAlchemy>=0.7.8,<=0.7.99 > > So you'll need an older version. (this is nothing personal about the author of the above words, this is a general situation in OpenStack that what I wrote about SQLA didn't get through enough) Lucky, other SQLAlchemy 0.8.2 issues have been mostly dealt with in this cycle, and the above bug is only about downgrading (when using SQLite 3), so it has very little practical consequences. And I am very happy of that. Thanks everyone for making this happen. >> *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" ...). >> > > The hard work of integration is making things work with what you have. > We will do everything we can to stabilize the requirements as quickly as > possible. Yes, freezing the requirements a bit earlier in the release cycle than we did for Havana would help a lot. I'd say at least 2 or 3 weeks before what we did this time. > I think you've done a fine job Thanks! > I think OpenStack in general has been responsive to your feedback. Yes! :) And it's been a pleasure. Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev