Call for agenda for Server SIG Weekly Meeting (2015-04-28)
sgallagh at redhat.com
Tue Apr 28 11:01:50 UTC 2015
This week, I think we need to discuss plans for Fedora 23.
Many people continue to ask if Fedora Server plans to have a long-term
maintenance release in the future. Thus far, we've all been pretty
much in agreement that we aren't ready for that.
The problem with a long-term release is, of course, personnel. It's
not terribly exciting to provide support on older (sometimes outdated)
packages, so no one really wants to do it without a really compelling
reason (in Ubuntu, this is usually - but not always - a paycheck from
However, a long-term maintenance release is a potential _solution_,
not a description of the problem. Looking at the real problem behind
it, the issue is actually "I need a guarantee that software I run atop
this is expected to continue working for X months/years." What this
really means is that the supported APIs and ABIs on the system
continue to behave the same way for an extended period of time. This
is orthogonal to the problem of packages.
So my proposal for Fedora 23 is that we de-emphasize the user-visible
engineering for a release in favor of working on tools to enable us to
better maintain API and ABI across releases. For example, I think we
need to be developing a taskotron tool to monitor for C/C++ ABI
changes in any /usr/lib library that we ship in the default Fedora
Server install. Such a tool should disable auto-pushing to stable if
the ABI changes in an incompatible way.
The other thing we should be doing is gathering API documentation into
a common place where we can decide which of the default packages we
install should be considered "stable" API (possibly defined as "stuff
we agree must work for 2-4 releases, even if this means maintaining a
compat package for a while").
So in short, my proposal is for us to research what we are shipping in
terms of libraries and APIs (such as D-BUS), gather their
documentation in one place and use this as a basis to build tools to
help us ensure that they stay functional for multiple releases.
Let's discuss this at the meeting today.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part
More information about the server