Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   EPEL Development (http://www.linux-archive.org/epel-development/)
-   -   Supporting other repositories. (http://www.linux-archive.org/epel-development/189559-supporting-other-repositories.html)

"Karsten 'quaid' Wade" 11-07-2008 05:50 PM

Supporting other repositories.
 
On Fri, Nov 07, 2008 at 11:10:08AM -0700, 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.

I'm the POC in Community Architecture for Fedora Directory Server,
FreeIPA, and Dogtag. It would be really cool to work more directly
with them on the layered products stuff. They share a common clued
product manager (Kevin Unthank). They have a strong interest in
working with us on community development.

Should we invite Kevin and the lead developers for those three
products, plus any other interested team mates, to epel-devel-l to
discuss?

Let's clear out the tough question, which I have not seen addressed.

Part of the original premise (promise?) of EPEL is that it would *not*
replicate Red Hat's layered products. We sat down with Tim Burke and
Daniel Riek (RHEL engineering and product management) at FUDCon in
Boston, and that was a clear and important point from their end of the
conversation.

How are we planning on addressing that?

For one, I think going to the individual layered products, one at a
time, and working with them on EPEL strategy makes sense. A bottom-up
approach, otherwise we'll never get to the point of resolving the
actual problems of the setup.

Any other thoughts?

- Karsten
--
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Thorsten Leemhuis 11-07-2008 06:33 PM

Supporting other repositories.
 
On 07.11.2008 19:50, Karsten 'quaid' Wade wrote:

On Fri, Nov 07, 2008 at 11:10:08AM -0700, 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.


That can easily and quickly get messy for everyone involved if (a) users
enable more then one of those layered repos and (b) there is more then
just the software you want (e.g. libs, perl modules, other stuff that
the software you want requires) in the those layered repos (which afaics
is the case).


In other, clearer words: Users will sooner or later run into repo mixing
problems that are similar to those that users faced when they tried to
enable different add-on repos for Fedora (say atrpms, freshrpms and
livna) at the same time.


Sure, most of those problems can be prevented before they happen by a
lot of coordination in the first place. But it's afaics way easier for
everyone to just put everything in one repo where people are working
together already.


> [...]

Part of the original premise (promise?) of EPEL is that it would *not*
replicate Red Hat's layered products. We sat down with Tim Burke and
Daniel Riek (RHEL engineering and product management) at FUDCon in
Boston, and that was a clear and important point from their end of the
conversation.

How are we planning on addressing that?


The meeting you refer to was 21 months ago iirc (Fudcon Boston 2007).
Maybe the opinions of those two changed in between, now that EPEL is
properly running for some time? Might be worth a quick check.


> [...]

CU
knurd

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Dennis Gilmore 11-07-2008 06:55 PM

Supporting other repositories.
 
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

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.

we should get what we can of spacewalk in except for the bits needing oracle
since they dont meet the guidelines yet. Spacewalk has said from the start
that it will work to get in EPEL. as to other layered products we have always
said that it will be up to the individual team if they wish to have their
product in EPEL.

I personally feel that having the product in EPEL will help not hinder sales.
those people who wont pay for support will still not pay for support. those
on the fence may deploy the product because of the easier route to
installation and decide that once installed and in production they need
support. Those customers who are willing to pay and want support will
continue to do so.

Dennis
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

"Stephen John Smoogen" 11-07-2008 07:34 PM

Supporting other repositories.
 
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.
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.
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.



> 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.
>
> we should get what we can of spacewalk in except for the bits needing oracle
> since they dont meet the guidelines yet. Spacewalk has said from the start
> that it will work to get in EPEL. as to other layered products we have always
> said that it will be up to the individual team if they wish to have their
> product in EPEL.
>

In no way am I saying to bring in/enable a product that doesn't want
to be there.. I am sorry my writing led you to believe that.

> I personally feel that having the product in EPEL will help not hinder sales.
> those people who wont pay for support will still not pay for support. those
> on the fence may deploy the product because of the easier route to
> installation and decide that once installed and in production they need
> support. Those customers who are willing to pay and want support will
> continue to do so.
>
> Dennis
>
> _______________________________________________
> Spacewalk-devel mailing list
> Spacewalk-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-devel
>



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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Michael DeHaan 11-10-2008 09:39 PM

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.



++

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list


All times are GMT. The time now is 05:38 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.