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@xxxxxxxxxx) 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 -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
