We are evaluating building packages from Fedora Extras for RHEL

[Thorsten Leemhuis]

Hi All!

It's not a big secret anymore, but wasn't announced yet in the public:
We, the Fedora Extras Project, are planing to "do the next step" and
start building lots of our packages for Red Hat Enterprise Linux and
compatible distributions like -- for example -- CentOS.

Not much is set into stone yet -- some people from Red Hat, FESCo and
selected Fedora community members were until now just roughly evaluating
the idea on a private list. It was agreed on that it's a good idea and
that we want to realize it, if possible and supported by the community.
Thus we move the discussion into the public hereby and want to continue
in the public from now on. This list (fedora-extras-list at redhat.com) and
the belonging discussion-channel #fedora-extras on freenode will serve
as the discussion platform for now.

The rough plan can be found in the wiki at
http://www.fedoraproject.org/wiki/Extras/Enterprise

Feel free to add or improve stuff on that page -- that's why it's a
wiki! ;-)

There are still lot's of details that need to be worked out but I'm sure
we'll get them sorted out. But some rough edges were mostly agreed on:

 * We start this effort as Extras-SIG (special interest group) that
directly works together with FESCo to drive this whole concept forward.

 * The packages build for RHEL shall be published to public repositories
to make sure that RHEL-compatible repositories like CentOS have access
to the results

 * It's important for several FESCo-Members that we use the Fedora
Extras infrastructure as much as possible

But let me use this opportunity to bring your attention to the most
important things that need to be discussed:

 = The name question =

We don't have a proper name for this effort yet. The "codename" until
now was Enterprise Extras (EE) (it is used in this document in several
places due to the lack of a better one), but we are currently evaluating
other names. There were several suggestions:

 * Fedora Extras (e.g. no special name)

 * Enterprise Extras (EE)

 * Fedora Extras Enterprise (FEE)

 * Fedora Enterprise Extras (FEE)

 * Fedora Extras for Red Hat Enterprise Linux (FERHEL)

 * Fedora Extras for Enterprise Linux (FEEL) or (FEfEL)

There were several comments to this name suggestions. Here are the most
important ones:

 * having "Fedora" in the name...

  * ...might be confusing because the results from it are for RHEL/CentOS

  * ...might be a good idea because it shows that the stuff is
unsupported by Red Hat

 * having "Enterprise" in the name...

  * ...shows that the packages are for Enterprise Distributions like
RHEL/CentOS

  * ...might suggest too much about the _type of software_ that is
offered, instead of the target distribution the software is built for.

 * having "Red Hat" in the name...

  * ... might lead to people assuming it's for RHEL only, but it's meant
for CentOS, too

When we agreed on a name we'll properly create a separate mailing-list
for further discussions specific to EE.

 = The support question =

As you all probably know, RHEL and CentOS are supported for round about
seven years normally and thus we need to make sure that the packages we
build for these Enterprise Distributions are supported for the same time
frame. "Supported" in this context means that security problems need to
be fixed in a timely manner after they were published. This normally
will be the maintainers job, but a security SIG -- either a special "EE
Security SIG" or the normal one we already have -- should watch the
maintainers and kick them if they missed something. The SIG also should
act as a fall back and step in to fix stuff if the maintainer doesn't --
but they can't fix each and every security problem alone so it only
needs to be a fall back.

So we somehow need to make sure that maintainers for EE know their
responsibilities. Suggestion how this could be done are welcomed. Maybe
only certain and well know FE contributors get allowed to build for EE
in the beginning

 = The quality problem =

In Fedora Extras the burden to make sure new or updated packages work
fine mostly is -- after the QA during package review -- only in the
hands of the maintainer itself as there is no {updates-,}testing repo
where updated packages get tested by other people or on archs that to
which the package maintainer has no access to. That mostly works fine
for FE (some people think that's a problem there, too, but that's
another story), but is it wise to lay all the QA in the hands of the
packager for a repository that builds for and Enterprise Distribution?

Closely related is the updates scheme EE should use -- do we use the FE
"rolling release" approach? Or do we want to try a mix like "Updated
packages in EE are allowed (Rolling Release), but they normally should
be build and published a certain time frame in the repositories for FE
first before they are published for EE"?

 = The co-maintainership problem =

We really need proper co-maintainer soon for this effort together with
the things co-maintainership implies -- e.g. the package database and
maybe restricted access in the VCS. We can start without proper
co-maintainership, but it should make stuff a lot easier.

 = EOF =

CU
thl