[Openstack-sigs] [lts] Support releases for a longer period of time

Thierry Carrez thierry at openstack.org
Wed Nov 15 13:52:07 UTC 2017


Hi everyone,

During the summit I promised a write-up of the "Long Term Support"
session outcome, as a start to drafting a plan and rally troups around
it. I unfortunately took a couple of days off to camp in Australia, and
by the time I came back (yesterday night) the thread had already split
into two mailing-lists and a dozen tangent topics (which was precisely
what I was trying to avoid in the first place).

As suggested by Rocky, I restart the discussion under a few threads on
the openstack-sigs ML, under the [lts] prefix, which will very likely
end up being used by a SIG looking into longer-supported releases.

The problem we are trying to solve is that our current stable branch
maintenance is not useful to most deployers of OpenStack software: we
EOL the branches after 12 months, while most deployers run 2- or 3-year
old releases.

The most obvious solution is to support branches for a longer time. The
issue with this is that as time passes, maintaining our stable branch
test infrastructure becomes more costly: the substrate (OS, libraries)
onto which we run our tests evolves, bugs are introduced and need to be
debugged etc. For years we've been calling for more resources to help
there, with no success. The fact is that the people who can work on that
area (at the intersection of infra, QA and stable branch maint) are
difficult to find.

At the "LTS" session in Sydney we've tried to not rehash one more time
the same "solution", but thinking a bit more out of the box and find
other solutions. One suggestion that seemed to get some momentum in the
session was the idea of letting self-appointed teams to continue the
maintenance of the branches at EOL. Not all branches would find an
interested team to maintain them for a longer period of time, and that's
ok. It would also not be considered part of a project team work to
produce backports for those branches: the proposal should not result in
additional work for existing teams.

That solution is being further explored in an etherpad, which you can
find at: https://etherpad.openstack.org/p/LTS-proposal

The threads that were created diverged to explore other ideas, like
skip-upgrade releases or longer cycles. While those are interesting
discussions to have, I think they are complementary rather than
alternative. We need to work on both upgrades and longer support. It's
likely not the same people working on each anyway.

I'll start a separate thread on longer cycles.
Cheers,

-- 
Thierry Carrez (ttx)



More information about the openstack-sigs mailing list