EPEL acceptance policy

[Tim Burke]

Hi,

I was just checking out the acceptance policy listed here:
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenan...

There's a few acceptance criteria that I think it would help to 
blatantly spell out there.  Perhaps this is really nit points and could 
be safely assumed, but I think it doesn't hurt to spell things out.

I think the intention is to not ship in EPEL stuff which RH already 
ships. Specifically this is stated as: "Thus packages from EPEL should 
never replace packages from the target base distribution"

I'm wondering if people may misinterpret that to think that things not 
on the base RHEL isos are fair game for replacement.  Layered products 
from RH which are delivered separately from the OS come to mind.  
Another example would be packages which are only intended for certain 
release variants.  For example, the GFS cluster components are not 
available to desktop / client configurations - server only.

Tying to think of an alternative recommended wording:

"thus packages from EPEL should never replace packages delivered by Red 
Hat - including those on the base distribution as well as layered products."

[Stephen John Smoogen]

On 3/12/07, Tim Burke <tburke(a)redhat.com&gt; wrote:
>  Hi,
>
>  I was just checking out the acceptance policy listed here:
>  http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenan...
>
>  There's a few acceptance criteria that I think it would help to
>  blatantly spell out there.  Perhaps this is really nit points and could
>  be safely assumed, but I think it doesn't hurt to spell things out.
>
>  I think the intention is to not ship in EPEL stuff which RH already
>  ships. Specifically this is stated as: "Thus packages from EPEL should
>  never replace packages from the target base distribution"
>
>  I'm wondering if people may misinterpret that to think that things not
>  on the base RHEL isos are fair game for replacement.  Layered products
>  from RH which are delivered separately from the OS come to mind.
>  Another example would be packages which are only intended for certain
>  release variants.  For example, the GFS cluster components are not
>  available to desktop / client configurations - server only.
>
>  Tying to think of an alternative recommended wording:
>
>  "thus packages from EPEL should never replace packages delivered by Red
>  Hat - including those on the base distribution as well as layered products."
>  
Well the one problem I can see that is a bootstrap problem.. if RHEL
picks up some subset of EPEL packages for its own subchannel. However,
that is really nitpicking something to death.


-- 
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"

[Tim Burke]

Stephen John Smoogen wrote:
>  Well the one problem I can see that is a bootstrap problem.. if RHEL
>  picks up some subset of EPEL packages for its own subchannel. However,
>  that is really nitpicking something to death.
>
>  
Good point.  In this case I think the package would naturally stop 
evolving in EPEL, as the incentive for inclusion would be removed.  
However, that transition (exit?) would be purely voluntary on the part 
of the EPEL pkg maintainer ... as RH isn't going to "force" it.

Similarly, what to do if a package is included in RHEL5 but not in 
RHEL4. I would think its fair game for EPEL to build the RHEL4 version 
but not the RHEL5 version.

[Michael Stahnke]

Does CentOS or another distro recompile/package the other RH channels
that are not RHEL?  I mean, if EPEL is people looking for best-effort
supported packges, might they want the application server under
best-effort rather than through a pay channel?  I am not saying we
should replace the channels, really I am mostly curious.

MIKE

On 3/12/07, Tim Burke <tburke(a)redhat.com&gt; wrote:
>  Stephen John Smoogen wrote:
>  >
>  > Well the one problem I can see that is a bootstrap problem.. if RHEL
>  > picks up some subset of EPEL packages for its own subchannel. However,
>  > that is really nitpicking something to death.
>  >
>  >
>  Good point.  In this case I think the package would naturally stop
>  evolving in EPEL, as the incentive for inclusion would be removed.
>  However, that transition (exit?) would be purely voluntary on the part
>  of the EPEL pkg maintainer ... as RH isn't going to "force" it.
>
>  Similarly, what to do if a package is included in RHEL5 but not in
>  RHEL4. I would think its fair game for EPEL to build the RHEL4 version
>  but not the RHEL5 version.
>
>  _______________________________________________
>  epel-devel-list mailing list
>  epel-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/epel-devel-list
>

[Mike McGrath]

Michael Stahnke wrote:
>  Does CentOS or another distro recompile/package the other RH
> channels
>  that are not RHEL?  I mean, if EPEL is people looking for best-effort
>  supported packges, might they want the application server under
>  best-effort rather than through a pay channel?  I am not saying we
>  should replace the channels, really I am mostly curious. 
I'm not touching that
with a ten-foot pole.  IMO if it ships in any 
version RHEL-x, it doesn't ship in EPEL-x.

    -Mike

[Michael Stahnke]

That's probably the correct answer Mike.  Consider my
question/comment/mail withdrawn.

On 3/12/07, Mike McGrath <mmcgrath(a)redhat.com&gt; wrote:
>  Michael Stahnke wrote:
>  > Does CentOS or another distro recompile/package the other RH channels
>  > that are not RHEL?  I mean, if EPEL is people looking for best-effort
>  > supported packges, might they want the application server under
>  > best-effort rather than through a pay channel?  I am not saying we
>  > should replace the channels, really I am mostly curious.
>  I'm not touching that with a ten-foot pole.  IMO if it ships in any
>  version RHEL-x, it doesn't ship in EPEL-x.
>
>      -Mike
>
>  _______________________________________________
>  epel-devel-list mailing list
>  epel-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/epel-devel-list
>

[Stephen John Smoogen]

On 3/12/07, Tim Burke <tburke(a)redhat.com&gt; wrote:
>  Stephen John Smoogen wrote:
>  >
>  > Well the one problem I can see that is a bootstrap problem.. if RHEL
>  > picks up some subset of EPEL packages for its own subchannel. However,
>  > that is really nitpicking something to death.
>  >
>  >
>  Good point.  In this case I think the package would naturally stop
>  evolving in EPEL, as the incentive for inclusion would be removed.
>  However, that transition (exit?) would be purely voluntary on the part
>  of the EPEL pkg maintainer ... as RH isn't going to "force" it.
>
>  Similarly, what to do if a package is included in RHEL5 but not in
>  RHEL4. I would think its fair game for EPEL to build the RHEL4 version
>  but not the RHEL5 version.
>  
Working on qa'ing the Centos-4.92 build.. I ran into a similar issue.
Upgrading from 3.8 or 4.4 leaves around 148 'orphans' on a system. I
am expecting that some of those might be candidates for EPEL-5.x as
people like squirrelmail etc.


-- 
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"

[Thorsten Leemhuis]

On 12.03.2007 21:36, Tim Burke wrote:
>  [...] 
>  Tying to think of an alternative recommended wording:
>  
>  "thus packages from EPEL should never replace packages delivered by Red 
>  Hat - including those on the base distribution as well as layered products." 
I'm fine with that mostly, but I have one big problem: I (and other
probably as well) might simply don't know what "layered products
from RH which are delivered separately from the OS" exists at all.

CU
thl

[Warren Togami]

Tim Burke wrote:
>  I'm wondering if people may misinterpret that to think that
> things not 
>  on the base RHEL isos are fair game for replacement.  Layered products 
>  from RH which are delivered separately from the OS come to mind.  
>  Another example would be packages which are only intended for certain 
>  release variants.  For example, the GFS cluster components are not 
>  available to desktop / client configurations - server only.
>  
>  Tying to think of an alternative recommended wording:
>  
>  "thus packages from EPEL should never replace packages delivered by Red 
>  Hat - including those on the base distribution as well as layered 
>  products." 
A few months ago Daniel Riek, Jesse Keating and theorized an easy to 
understand policy to recommend for EPEL.

Layered products themselves are not duplicated in EPEL.  EPEL provides 
layer repos that are built upon and require a corresponding RHEL layer.
	
(these are not actual layer names, just examples)

EPEL5 Bar requires RHEL5 Bar
EPEL5 Foo requires RHEL5 Foo
EPEL5 requires RHEL5 base

Where the user chooses to use an EPEL layer, they must have the 
underlying layer from some source.

Red Hat cannot stop an external project from building clone layers. 
This layered repo recommendation tries to be a clearly understood and 
fair compromise that recognizes this reality.

I hope EPEL can accept something like this as in the EPEL5 policies.

Warren Togami
wtogami(a)redhat.com