Hello list,

I'm a new comer to the Red Hat world. I have been using Debian and
derivatives for many years, but for the past 3 months I have been
working on a 100% Fedora shop. So I still consider myself an outsider,
even though I suppose that I can improve the conversation about
EPEL's future.

In a nutshell, this shop have been using Red Hat since forever. When
RH decided to start focusing on the enterprise, Fedora was the logical
choice at the time. The six months release cycle, the extremely
bleeding edge approach (they told me that up to Fedora Core 6 things
did not use to brake between releases) and the small 1 year of
updates/security support made the administration and management of
servers and desktops almost impractical. Fedora Legacy was gone too.

The general consensus was: we need a stable OS, long term security
support (at least 2,5 to 3 years) with good and vast packaging
availability.

Options that were being considered:
1) Debian
2) RHEL
3) CentOS

Well, unfortunately Debian was a no go due to the strong RH culture
(as I said, RH users since forever) even fulfilling the requirements.
Paying for RHEL ended up not being an option too. So our best option
is CentOS. I think I don't have to introduce CentOS here.

Right now the only complaint we have is the small number (I personally
consider a huge lack) of packages available on the default
repositories. I was shocked that there is no apcupsd package on the
default CentOS.

Then we have found many stuff that we need in EPEL, some of them are
not the latest version, but they are not too outdated to become
useless to us.

So here is my idea:

Follow the RHEL release cycle.

Freeze EPEL. Update packages to fix important/security bugs. No major version.

During this freeze, work on the unstable branch, upgrading those
packages that really need a re-base due to many reasons already
discussed on the other thread, small version upgrades when possible.
New packages. Just do what RH does.

New RHEL released. Push the new stuff to EPEL 'current' and make a
release note about it, reporting packages that have been removed,
upgraded, changed behavior, etc. Then the cycle begins again.

I call this a "semi-distribution" release or something like that.

I really see this as a win-win situation:
- Changes are predicted and almost at the same time of a major release.
- There is room for upgrades and they can be tested. Open a window for
accepting new stuff then close it.
- You have a test server, upgrade to 5.3 following the packages from
EPEL. Everything OK? Then go to the production servers and just relax
for the next 6 months since every single repository is NOT going to
put a new version of any package.

And seriously, IMHO there is NO WAY to keep EPEL up to Fedora or to
every upstream package.

What do you think?

Miguel

--
http://osysadmin.blogspot.com

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Tue, Jul 1, 2008 at 4:49 PM, Miguel Filho <miguel.filho@gmail.com> wrote:
> Hello list,
>
> I'm a new comer to the Red Hat world. I have been using Debian and
> derivatives for many years, but for the past 3 months I have been
> working on a 100% Fedora shop. So I still consider myself an outsider,
> even though I suppose that I can improve the conversation about
> EPEL's future.
>

Thanks for the feedback.. sorry it took me a while to come back to this.

> Follow the RHEL release cycle.
>

The question is which release cycle. There are several.

Big release cycle:
RHEL-2,3,4,5 which have an average release time of 20 months between
versions. [By this estimate RHEL-6 would be released in October of
2008, but my guess is it would be later than that.]

Small release cycle:

RHEL-4.0, 4.1,.. 4.6, 4.7
RHEL-5.0, 5.1, 5.2, 5.3

these are released every 6 months or so.

> Freeze EPEL. Update packages to fix important/security bugs. No major version.
>
> During this freeze, work on the unstable branch, upgrading those
> packages that really need a re-base due to many reasons already
> discussed on the other thread, small version upgrades when possible.
> New packages. Just do what RH does.
>
> New RHEL released. Push the new stuff to EPEL 'current' and make a
> release note about it, reporting packages that have been removed,
> upgraded, changed behavior, etc. Then the cycle begins again.
>
> I call this a "semi-distribution" release or something like that.
>
> I really see this as a win-win situation:
> - Changes are predicted and almost at the same time of a major release.
> - There is room for upgrades and they can be tested. Open a window for
> accepting new stuff then close it.
> - You have a test server, upgrade to 5.3 following the packages from
> EPEL. Everything OK? Then go to the production servers and just relax
> for the next 6 months since every single repository is NOT going to
> put a new version of any package.
>
> And seriously, IMHO there is NO WAY to keep EPEL up to Fedora or to
> every upstream package.
>
> What do you think?
>

This was exactly what the original EPEL was looking to try. The
problem was that there were probably 3-5 people who were willing to
work on the unstable stuff and requests for hundred's and hundred's of
packages... and lots of requests for newer stuff than what was in
EPEL. Stability is hard.. its why few people work on Debian Stable
and people pay Novell, Red Hat etc for their long life releases.






--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list