Open Stack

Excerpts from Thierry Carrez's message of 2015-03-04 02:19:48 -0800:
> 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.
> 

I think the value of coordinated releases has been agreed upon for a
long time. This thread is more about the cost, don't you think?

> >> 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.
> 

I don't believe that the kernel reached maturity as a point of
eventuality. Just like humans aren't going to jump across the grand
canyon no matter how strong they get, it will take a concerted effort
that may put other goals on hold to build a bridge. With the kernel
there was a clear moment where leadership had tried a few things and
then just had to make it clear that all the code goes in one place, but
instability would not be tolerated. They crossed that chasm, and while
there have been chaotic branches and ruffled feathers, once everybody
got over the paradox, it's been business as usual since then with the
model James describes.

I think the less mature a project is, the wider that chasm is, but I
don't think it's ever going to be an easy thing to do. Since we don't
have a dictator to force us to cross the chasm, we should really think
about planning for the crossing ASAP.

> >>  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 :)
> 

I'm not super excited about being an apple or an orange, since neither
are sentient and thus cannot collaborate on a better existence than
rotting.