Update strategy (was: Re: TestDisk in EPEL ?)

Stephen John Smoogen smooge at gmail.com
Tue May 15 21:13:04 UTC 2007


On 5/15/07, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> Hi all!
>
> I got below mail in private and wanted to discuss it here in the open
> (got permission from the Christophe to forward his mail here).
>
> On 13.05.2007 21:16, Christophe GRENIER wrote:
> > On Sun, 13 May 2007, Thorsten Leemhuis wrote:
> >> Building you Fedora packages for EPEL (Extra Packages for Enterprise
> >> Linux -- http://fedoraproject.org/wiki/EPEL ) is possible for some
> >> months now. But it seem lots of Fedora contributors wait for a kind of
> >> start signal to begin. *This mail is this start signal*, as we have all
> >> the important pieces in place now! So go and build your Fedora packages
> >> for EPEL if you want, to have your packages easily available for RHEL
> >> and compatible derivates such as CentOS or Scientific Linux in the
> >> future as well!
> >> ...
> >> Is EPEL a rolling release like Fedora Extras was? No, the plan is to
> >> have a update strategy similar to the one from RHEL. E.g. ship software
> >> once and only update it to later versions if there is a strong need --
> >> so no "hey, there is a new version, it builds, let's ship it" mentality
> >> in EPEL please. See
> >> http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies for more details.
> > [...]
> > I think that TestDisk and PhotoRec should be avaible for RedHat Enterprise
> > but as they are recovery utilities , it's usually/always better to use
> > latest version. Should I request an EPEL branch and update to new
> > version (if recovery has been improved) 2/3 weeks after fc-devel package ?
>
> My 2 cent:
>
> * updates always bear risks.
>
> * updates especially bear risks if the combination of app + libs +
> kernel is not tested much. That happens in RHEL quickly, as libs and
> kernel are not moving much (while app moves and will likely get testing
> with more recent libs and kernels).
>
> * users choose RHEL because it doesn't move much -- why should a add-on
> repo be different?
>

Ok my experience supporting RHEL at two government laboratories and
talking with people at large organizations. There are multiple
audiences for add-on repos that follow the classic markets
(http://en.wikipedia.org/wiki/Crossing_the_Chasm): innovators, early
adopters, early majority, late majority,  and laggards.


The innovators were the people who had to have RHEL-2.1 due to a
programatic reason (the core app would only work on 2.1) but needed
also the latest php modules on it. We could not support this directly,
but helped out with a repository where they could put in alternative
packages to replace items til they got what they wanted. Or they
wanted RHEL-5 with Thunderbird-2.x. Or they are putting a 2.4.30+
kernel on 2.1 etc. They normally use Fedora/etc but cant in some
situations and innovate to make it work.

The early adopters wanted RHEL-5 with additional items and some level
of replacement. They wanted the newest version of say moin, clustering
application etc as they are usually wanting the best new experience
for their 'customers'... but want more stability in the backend. Most
are served by a Fedora or the Red Hat Global Desktop.. but may need a
core set of items (glibc/kernel) stable for some programmatic reason

The early majority wants stability with updates occuring at known
times. They want technology refreshes, but want a seal of approval of
some sort that the organization is steady, has standards, or has a
company that will stand behind it. They also want the same thing as
close to possible on as many of their systems (as they will have
RHEL-3,4, and 5 deployed as servers that they want to add stuff to).

The late majority want stability over anything. They are the ones who
are starting to cycle out RHEL-1 and RHEL-2.1 systems to 4 systems
when they get new hardware. They want to have the same version of moin
supported for 7 years (just in case they need to keep a server that
long up).

The laggards are moving from RHL-6.2 to maybe RHL-3.9 or RHL-4.5 in
the next couple of years. If they want external stuff, they will have
Oracle/IBM/etc do it for them.


Which of the customer bases does EPEL want to look at?


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




More information about the epel-devel-list mailing list