Open Stack

Mark McLoughlin wrote:
>> a) We continue to focus development efforts of master on the latest 
>> release of Ubuntu with python libraries coming from PyPI.
> 
> I'd say "latest release of Fedora" too - e.g. devstack not working on
> the latest Fedora release would be understood as a bug by everyone IMHO.

I think we are trying to define two different things: "representation of
what the current state of Linux is" (for development focus), and
"representation of what is still used in the wild" (for what we should
strive to not break).

Saying we focus development efforts on "latest release of Ubuntu with
python libraries coming from PyPI" is a way to describe "current" in
technical terms. We could certainly add "and latest release of Fedora
with python libraries coming from PyPI", but I'm not sure it would move
the target that much (due to most things coming out of PyPI anyway),
while it would add some complexity.

Additionally Fedora represents more, to my eyes, "what a current Linux
distribution will be", due to its... tendency to embrace experimental
features early :) That said, this could actually be seen as positive: a
good way, for us, to anticipate changes a bit (4-month old Ubuntu +
3-month old Fedora could be a pretty good description of "current").

> I wouldn't discount us saying "latest release of Debian or SuSE" too.
> I'm not just clear whether that's already the reality (i.e. we work on
> two recent distros, other recent distros "just work" and no-one says
> anything") or whether it really is just Ubuntu or Fedora we are
> consistently in good shape on.

I fear that it would move us a bit far away from "representation of
current" to bleed into "representation of what is used in the wild". See
below.

>> b) We don't introduce things into master that would be unworkable on 
>> either latest Ubuntu LTS or latest RHEL.

Latest Ubuntu LTS + latest RHEL is a way to describe, in technical
terms, "what is still in use out there". We could add "latest Debian and
SuSE" to this mix, though I think their requirements would certainly be
covered by the above description.

You could object that it doesn't really add complexity to add more
distros in the description, and it's more "fair". Reality is we'll have
to compile what each description technically means ("Python 2.6.3 to
2.7.x", Kernel 3.2 to 3.5...) and that requires to keep an eye on all of
those distros to keep that description current. I can certainly picture
our current team keeping up to date with Ubuntu, Fedora and RHEL, not
sure about more.

> Never say never. Honestly, if someone showed up with fairly well
> advanced support for Python 3.x and that meant we absolutely had to drop
> Python 2.6 support, I'd be the first to say we should do it.
> 
> If that happened, Red Hat (and others) would have to just suck it up and
> maintain patches for 2.6 support. I'd think we (as a project) would
> provide whatever assistance is reasonable, though.

I'd really prefer if we could have a clear house rule, rather than a set
of ad-hoc decisions that nobody can anticipate. That doesn't mean we
can't have exceptions to the rule in really odd corner cases (say, if
RHEL decides the next version will actually be in 2025). But, in absence
of exceptions, everyone should know what the default rule is.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack