Stephen John Smoogen wrote:
On Fri, Nov 7, 2008 at 12:55 PM, Dennis Gilmore <email@example.com> wrote:
On Friday 07 November 2008 12:10:08 pm Stephen John Smoogen wrote:
Ok loaded term but I was wondering if we could work with spacewalk,
ipa, ds, etc to support their work by including at least a
spacewalk-release or similar item. This would allow us to 'test' the
waters of working closer with the other layered upstreams. Basically
instead of having to hunt around for every different repository, we
work with the upstream project ot have a signed release that works
with the EPEL releases.
Anyway.. back to dealing with local stuff.. I figured I should fire it
off before I forget.
Other than completely violating fedora's guidelines that EPEL is subject to.
I don't think its a good idea. It makes it too easy to not do the work needed
to get things into fedora/EPEL
The issue I am trying to deal with is several issues
1) we have RH-upstream-product-0.X needing something that RHEL-4/5 do
not ship in apache etc Its going to happen because thats just how
software projects go.
I think we need to take a big heavy stick to those projects.
As much as I'd love Python 2.5 on RHEL 4
2) we have stuff in EPEL that would replace a layered product. I mean
if we put spacewalk in and it replaces something from
RHN-supported-product. I really am not worried about sales.. someone's
going to make rebuilds available somewhere but I am trying to work out
a way that someone is not going to clobber themselves by having a RH
product and enabling EPEL on the box.
Mutual conflicts: tags should be sufficient.
3) product timeline does not match up with EPEL timeline. This happens
a lot with the cobbler/koan/func stuff where they are implementing
fixes but I could see it happening in say IPA etc. where they have a
midmonth release or 'just-a-bugfix' upgrade.
This is a consequence where it's important for products to target a
"version ____ or later" API
and be tolerant about what to do when applications are missing
features. Applications must also maintain
stable APIs that continue to work.
I encounter some of this with libvirt being more capable on newer
platforms but in all actuality it's not a
Generally our strategy to do this is web services, and applications
should support a method that returns the versions
of their API. For applications that are more tightly integrated
they'll have to make appropriate workarounds.
It is true that EPEL moves too slowly to get bugfixes out, though this
can be countered by pointing
folks at EPEL testing until some day where that could hopefully be run
more frequently and under Bohdi.
Needless to say, apps like Cobbler and Func are closely related to the
Spacewalk team here, so I don't really
see it being a problem with having different priorities. Making
Spacewalk successful is definitely a major
fedora-ds is in fedora I suggest that you ask richm to build fedora-ds into
EPEL. freeipa is in fedora also. we should talk with rcrit to get freeipa
branched and built for EPEL it will require fedora-ds to be there first.
epel-devel-list mailing list