Call for agenda for Server SIG Weekly Meeting (2015-04-28)

Stephen Gallagher 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 
Canonical).

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[64] 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...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20150428/8ac5d793/attachment.sig>


More information about the server mailing list