[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Spacewalk-devel] Re: Supporting other repositories.



Stephen John Smoogen wrote:
On Fri, Nov 7, 2008 at 12:55 PM, Dennis Gilmore <dennis ausil us> 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
big problem.

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
priority.



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.

++


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]