10:24 a.m.
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?
* there are "recovery utilities" in RHEL5 -- but even those only get
updates if there is a good reasons to
So my answer for this specific app would be: if there are minor TestDisk
versions (e.g. from 6.6-1.fc7 to 6.6-2 or 6.7-2) that *mainly* fix bugs
released over the next 2 or 3 years then feel free to update them in
EPEL *if* there is a really good reason for it. Major new versions that
that change behavior (e.g. command line options for example) should be
avoid if possible. After RHEL6 is out and settled for a while only touch
the RHEL5 TestDisk package if there is a strong need to and avoid even
minor versions.
That round about what
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies says afaics.
Other opinions?
Cu
thl
3:58 p.m.
On Tue, May 15, 2007 at 05:24:03PM +0200, Thorsten Leemhuis wrote:
Other opinions?
I think it would be nice to have more discussions on the epel list
where people ask others whether it is interestig to add a package, or
risky because it will leave a high burden on the epel maintainers or
deceive users.
--
Pat
4:13 p.m.
On 5/15/07, Thorsten Leemhuis <fedora(a)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"
11:59 a.m.
New subject: Update strategy
On 15.05.2007 23:13, Stephen John Smoogen wrote:
On 5/15/07, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
[...]
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.
Well, as you say, those use normally Fedora or Fedora-like distribution.
No need for EPEL to target those.
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
I'd say those people that only want some new apps and a stable backend
are best served with a local repo for the apps they need in up2date
version or other specific small repos. They can use the Fedora packages
as a base for it; EPEL probably can't serve those people with todays
tools (yum and co), as each and everyone defines stable backend differently.
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).
Those are IMHO round about one of the targets for EPEL -- even if there
is no company behind EPEL, they get stuff missing in RHEL easily with EPEL.
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).
They can use EPEL5 when RHEL6 or RHEL7 are out, as EPEL5 shouldn't move
much anymore and be quite stable.
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?
Hope that clarifies it.
CU
thl
12:54 p.m.
New subject: Update strategy
On 5/16/07, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
On 15.05.2007 23:13, Stephen John Smoogen wrote:
> 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).
Those are IMHO round about one of the targets for EPEL -- even if there
is no company behind EPEL, they get stuff missing in RHEL easily with EPEL.
I thought about this some more last night. Would the EPEL repository
be better suited with an 'alternate' tree structure?
X.old Last release
X.stable Current release
X..testing Stuff might be pushed to current release
X.rawhide Stuff that might go into testing for next release.
X.Y/SRPMS
X.Y/<arch>
with symbolic links to show the tree structure.
4.4 -> 4.old
4.5 -> 4.stable
4.6 -> 4.testing
4.7 -> 4.rawhide
This would allow people who are doing different levels of testing to
aim at a said set?
--
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"
4:21 a.m.
New subject: Update strategy
On 16.05.2007 19:54, Stephen John Smoogen wrote:
On 5/16/07, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
> On 15.05.2007 23:13, Stephen John Smoogen wrote:
>> 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).
> Those are IMHO round about one of the targets for EPEL -- even if there
> is no company behind EPEL, they get stuff missing in RHEL easily with EPEL.
I thought about this some more last night. Would the EPEL repository
be better suited with an 'alternate' tree structure?
X.old Last release
The plan is to leave all the old repos for X.X releases around; see
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-a98bce5283e...
X.stable Current release
Sure
X..testing Stuff might be pushed to current release
Under discussion -- we need to look if that's possible with bodhi.
X.rawhide Stuff that might go into testing for next release.
Hmm, I'd prefer to call it
X.testing
X.testing-stable
or something like that.
X.Y/SRPMS
X.Y/<arch>
with symbolic links to show the tree structure.
4.4 -> 4.old
4.5 -> 4.stable
4.6 -> 4.testing
4.7 -> 4.rawhide
Might be doable.
CU
thl
4:19 p.m.
New subject: Update strategy
"TL" == Thorsten Leemhuis <fedora(a)leemhuis.info>
"SJS" == Stephen John Smoogen
SJS> The early adopters wanted RHEL-5 with additional items
SJS> and some level of replacement. They wanted the newest
SJS> version of say moin, clustering application etc as they
SJS> are usually wanting the best new experience for their
SJS> 'customers'... but want more stability in the
SJS> backend. Most are served by a Fedora or the Red Hat
SJS> Global Desktop.. but may need a core set of items
SJS> (glibc/kernel) stable for some programmatic reason
TL> I'd say those people that only want some new apps and a
TL> stable backend are best served with a local repo for the
TL> apps they need in up2date version or other specific small
TL> repos. They can use the Fedora packages as a base for it;
TL> EPEL probably can't serve those people with todays tools
TL> (yum and co), as each and everyone defines stable backend
TL> differently.
That's about where we are right now. We're running CentOS on
servers and workstations because it's easier to maintain a local
set of packages for one OS (although we're currently spread out
over 3 and 4, with 5 the obvious upgrade path for the summer).
Our users don't need the latest and greatest cutting-edge software
for most things, but it is important that some tools (math-related
applications, TeX system, Subversion, etc.) be very recent.
I do have my own local repo, mostly with packages from Fedora and
Dag's RPMforge, and I expected that I would have to maintain that
for some packages (including packages Fedora can't/won't touch
because of licensing or patent issues but the users demand;
packages for commercial software that we definitely couldn't
distribute; and packages for software that may not be
distributable because of its licensing terms). But I was really
looking forward to having a single source for reasonably
up-to-date packages for the packages that are in Fedora.
From this discussion, it sounds like EPEL is targeting a
completely different set of end users. Given the general
political nastiness surrounding the whole repotags issue, it also
sounds like there isn't much interest in cooperating with the
other third-party repos, which makes EPEL a lot less attractive.
I'm still watching, but I'm leaning toward deciding that EPEL
isn't going to be worth bothering with.
Claire
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Claire Connelly cmc(a)math.hmc.edu
Systems Administrator (909) 621-8754
Department of Mathematics Harvey Mudd College
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
7:23 p.m.
New subject: Update strategy
Thorsten Leemhuis wrote:
So my answer for this specific app would be: if there are minor
TestDisk
versions (e.g. from 6.6-1.fc7 to 6.6-2 or 6.7-2) that *mainly* fix bugs
released over the next 2 or 3 years then feel free to update them in
EPEL *if* there is a really good reason for it. Major new versions that
that change behavior (e.g. command line options for example) should be
avoid if possible. After RHEL6 is out and settled for a while only touch
the RHEL5 TestDisk package if there is a strong need to and avoid even
minor versions.
That round about what
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies says afaics.
Other opinions?
Though there is no formal document yet afaik describing this process in
RHEL "leaf applications" are treated different from base applications.
Base applications are things like libraries which are other applications
depend upon. Leaf applications are things like TestDisk which is
independent. Leaf applications can be updated more regularly and chances
of regressions and the impact of any regressions is much less.
Also in some cases heavy backporting might result in more instability
compared to just updating to the newer version since such backporting is
very distribution dependent and is not widely tested and used by
upstream projects and the community.
You might want to classify and treat applications differently and have a
process for requesting exceptions if necessary.
Rahul
6207
days inactive
6214
days old
epel-devel@lists.fedoraproject.org
7 comments
5 participants
participants (5)
-
C.M. Connelly -
Patrice Dumas -
Rahul Sundaram -
Stephen John Smoogen -
Thorsten Leemhuis