Open Stack

Random comments inline

Robert Collins wrote:
> [...]
> So I think the test should actually be something like:
> Apply caution if it is not packaged AND packaging it is hard.
> Things that make packaging a Python package hard:
>  - nonstandard build systems
>  - C dependencies that aren't already packaged
>  - unusual licences
> 
> E.g. things which are easy, either because they can just use existing
> dependencies, or they're pure python, we shouldn't worry about.

Beyond being "difficult to package", I think there was the idea of
facilitating the distributions work by keeping them in the loop when we
add dependencies. In the past we had cases where OpenStack devs wanted
to add a library and distros had an already-packaged,
functionally-equivalent, and sometimes better-maintained library to
suggest instead. In some other, they had security issues with a library
that upstream wouldn't fix, and moved to another library as a result.
Involving them is a win-win.

Basically, it's not just about packaging: tapping into the distros
expertise when it comes to the state of the Python ecosystem was (and
imho still is) highly valuable to us. Saying "we'll pick whatever we
come up with as long as we think it's not a pain to package" is a bit
one-sided.

That said, on this repository we haven't seen the kind of involvement
from distros that we expected in return...

> On 22 August 2015 at 11:50, Dave Walker <email at daviey.com> wrote:
>>
>> The release schedule used to document a DepFreeze[0] to avoid nasty
>> surprises for distros, which used to be at the same point of
>> FeatureFreeze[1].  This reference seems to have been removed from the
>> last few cycles, but I would suggest that it could be re-added.
> 
> As more components of OpenStack are moving away from big-bang
> releases, DepFreeze would make less and less sense to me. The
> integrated release is on the way out.

I'm not so sure. DepFreeze is about facilitating the work of
distributions at the end of a development cycle so that they can release
packaged versions as close as possible to the end of cycle (a.k.a.
release) date. OpenStack gradually moving away from big-bang releases
has limited impact on that -- distros still do big-bang releases and
appreciate us slowing down on the dep addition front every 6 months.

We could say we no longer care about distro release cycle alignment, but
it served us well in the past.

-- 
Thierry Carrez (ttx)