Open Stack

James Bottomley wrote:
> On Tue, 2015-03-03 at 11:59 +0100, Thierry Carrez wrote:
>> James Bottomley wrote:
>>> Actually, this is possible: look at Linux, it freezes for 10 weeks of a
>>> 12 month release cycle (or 6 weeks of an 8 week one).  More on this
>>> below.
>>
>> I'd be careful with comparisons with the Linux kernel. First it's a
>> single bit of software, not a collection of interconnected projects.
> 
> Well, we do have interconnection: the kernel on it's own doesn't do
> anything without a userspace.  The theory was that we didn't have to be
> like BSD (coupled user space and kernel) and we could rely on others
> (principally the GNU project in the early days) to provide the userspace
> and that we could decouple kernel development from the userspace
> releases.  Threading models were, I think, the biggest challenges to
> this assumption, but we survived.

Right. My point there is that you only release one thing. We release a
lot more pieces. There is (was?) downstream value in coordinating those
releases, which is a factor in our ability to do it more often than
twice a year.

>> Second it's at a very different evolution/maturity point (20 years old
>> vs. 0-4 years old for OpenStack projects).
> 
> Yes, but I thought I covered this in the email: you can see that at the
> 4 year point in its lifecycle, the kernel was behaving very differently
> (and in fact more similar to OpenStack).  The question I thought was
> still valid is whether anything was learnable from the way the kernel
> evolved later.  I think the key issue, which you seem to have in
> OpenStack is that the separate develop/stabilise phases caused
> frustration to build up in our system which (nine years later) led the
> kernel to adopt the main branch stabilisation with overlapping subsystem
> development cycle.

I agree with you: the evolution the kernel went through is almost a
natural law, and I know we won't stay in the current model forever. I'm
just not sure we have reached the level of general stability that makes
it possible to change *just now*. I welcome brainstorming and discussion
on future evolutions, though, and intend to lead a cross-project session
discussion on that in Vancouver.

>>  Finally it sits at a
>> different layer, so there is less need for documentation/translations to
>> be shipped with the software release.
> 
> It's certainly a lot less than you, but we have the entire system call
> man pages.  It's an official project of the kernel:
> 
> https://www.kernel.org/doc/man-pages/
> 
> And we maintain translations for it
> 
> https://www.kernel.org/doc/man-pages/translations.html

By translations I meant strings in the software itself, not doc
translations. We don't translate docs upstream either :) I guess we
could drop those (and/or downstream them in a way) if that was the last
thing holding up adding more agility.

So in summary, yes we can (and do) learn from kernel history, but those
projects are sufficiently different that the precise timeframes and
numbers can't really be compared. Apples and oranges are both fruits
which mature (and rot if left unchecked), but they evolve at different
speeds :)

-- 
Thierry Carrez (ttx)