Open Stack

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.

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

>  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

The main difference is that our translation projects are not integrated
into our releases.  They're done mostly by the downstream (debian if you
look: the rest of the distros do invest in translations but they don't
make the upstream effort with them), so we don't specify what
translations we have, we allow interested parties to choose to help.

I would argue that the downstream is the best place to manage
translations because they decide which markets are important or
interesting, but if you still want to control this at the upstream end,
with Daniel's proposal, it would mean you only really need translations
for stable releases.

James

> The only comparable project in terms of evolution/maturity in the
> OpenStack world would be Swift, and it happily produces releases every
> ~2months with a 1-week stabilisation period.