Overlap policy v20120615

Bryan J Smith b.j.smith at ieee.org
Fri Jun 15 20:11:16 UTC 2012


Stephen John Smoogen <smooge at gmail.com> wrote:
> Well of course it is arbitrary. Any definition we use is going to be
> arbitrary because well there is no rock solid proof that says "this is
> RHEL" and "this isn't RHEL".

Actually, the leaders have done their best to try to define it.
Unfortunately, they are getting pulled in many directions.  I haven't
taken issue with some suggestions, but others are literally trying to
break down what used to be RHEL AS/AP.  That has stood for 10 years no
less.

With version 6, Red Hat offered to break out AS/AP into more "buy what
you want," so someone who just needed simple HA didn't have to buy the
5-10x product entitlement.  But now people are jumping on that to tear
it all down.  Why is that?  I think several people admitted why, and
how EPEL solves that for them rather than tapping CentOS directly.

All I know is that it is a mess that reminded me of several
enterprises that tried and stopped using CentOS Extras.  They wanted
extra packages they couldn't get from Red Hat.  When EPEL came around,
it solved it for them.  Now we're back to the same issue.

So how do we solve it for everyone?  I don't know.  The leaders really
have their work cut out for them.  One of the suggestions that might
work adds a burden on them, splitting it into two repos.  And even
that won't address everything.

> Expecting us to define that definition when it is clear that even
> Red Hat has no rock solid definition is preposterous.

Red Hat has _always_ had a rock solid definition of AS/AP.  Even
today, the version 6 entitlements map to AS/AP.  There's no reason to
end those, not after 10 years of lineage.  But some want to.  And some
have stated their reasons.  And I have pointed them out.

Expectations have been set prior.  But now they have changed, and are
still changing.  Conflicts will happen.  Changes will occur.  But
changes to expectations should be mitigated.

> So this is our arbitrary line in the sand. It is no better or worse
> than if we drew it 2 feet to the left or 2 feet to the right. However
> until the tide comes in and washes it away, this is the one we
> are looking to use.

But in the process, you have to realize who is being considered the
least.  We're far more worried about giving the least subsidizing Red
Hat customers everything they need, instead of also considering how
much that will conflict with Red Hat's biggest, subsidizing customers.

As I said, that is self-defeating for the project.

You have to recognize no one is important than anyone else.  From
there, you have to see what can and should be done.  If there is an
argument that EPEL will lose packages and maintainers and that's the
sole focus, I think people forget the flip side of that.

Not only is there no reason why packages and maintainers can't work on
the packages in a similar effort, possibly a separate Fedora repo or
an external one, but the best one of all.  Sit back and work this
through ... I mean, wouldn't it be nice if Red Hat could employ them
so they could do the packages full time?

Just remember that consideration as well.  ;)


--
Bryan J Smith - Professional, Technical Annoyance
http://www.linkedin.com/in/bjsmith




More information about the epel-devel-list mailing list