Relationship to existing 3rd party repos/CentOS/SL?

[Michael Stahnke]

On 4/14/07, Rex Dieter <rdieter at math.unl.edu> wrote:
> Jeff Sheltren wrote:
> > On Apr 14, 2007, at 11:42 AM, Rex Dieter wrote:
>
> >> Frankly, if someone feels that they don't think it important to play
> >> nice (and do the right thing, imo), I would rather they not be involved
> >> in this project.
>
> > That seems rather blunt and unnecessary.
>
> Blunt, yes.  Necessary, I think so.  For me personally anyway, this is
> very important for project relations.
>
> > Hi Rex, I'm confused if you are suggesting you'd rather I'd not be
> > involved in EPEL because of my above statement?
> ...
> > Maybe I am blowing this out of proportion.
>
> I think so, and certainly not my intention to imply anything against you
> personally.  Please stay.  :)
>
> > Has someone proposed a set
> > of guidelines for repos to follow that you feel would be somewhat easy
> > to enforce?
>
> No one is suggesting red-tape, rules, regulations, enforcement (I hope
> not, anyway).  I'd argue public/stated intentions/goals (to play nice)
> and a best effort to follow through on said intentions is wholly sufficient.
>
> -- Rex
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>

>From my perspecitive, and from my company's prospective, EPEL is going
to be a very nice thing.  Today (my team) we grab packages for RHEL
from several big third party repos and then recompile them ourselves.
The main reason is, we don't know what type of QA/Testing/Packaging
Guidelines have been applied.[1]  There have been several src.rpm
packages over the years that we grabbed from one repo and gave up on
becuase of odd macros, strange dependencies, or replacing a core
package from RHEL.  With EPEL, I am quite sure that won't happen.
Also, the QA process is understood and recognized.  I admit it isn't
the greatest QA process, and leaves room for improvement, but at least
it is understood, and "trusted" by companies who realize that RHEL is
spawned from Fedora.


 This isn't a knock on other 3rd party repos, I like them a lot, and
they have done a bunch for the open source community.  I guess I feel
that if the package can be part of EPEL, it should.  It will make life
easier for the EL consumer, and that's who I want to please, EL
customers who need packages traditionally not available in EL.  I
would love 3rd party repos to continue to carry newer packages, kernel
modules and those fun non-US-legal packages.

I do think working *with* the owners of these repos is critical.  I
want their expertise.  I want their years of knowledge and point of
view.  (I also voted for the repo tag becuase EPEL isn't the only game
in town).

So, Axel  brings up some very good questions about how EPEL can and
will interact with 3rd party repos.  Could the Fedora permissable
packages move to EPEL without a political battle?  I have no idea.
Could the major 3rd party repos become very compatible with EPEL? I
hope so.


stahnma

[1]Someone could quickly argue that I/my team should have looked into
the QA/build processes of these 3rd party repos, understood them,
joined mailing lists, etc.  And, it's a valid argument, but it didn't
happen. One package we needed was from one repo, another from another
and so on.