Open Stack

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