I was trying to reply to everything inline, but being the responsible
posters ya'll are, you trimmed and everything leaving context harder to
just jump in on :)

Way back in the day when I had a lot more time to spend on EPEL, I loved
it. There were a few assumptions made then that I think don't hold up now.

1. 5 year lifecycle. 5 years is doable in a stretch by some maintainers.
Now, it's 10 or 13 years depending on how you slice your RHEL support.
That's too long for any volunteer.
2. Upstreams move a heck of a lot faster. As users/developers started
trusting update mechansims more and speed/agility were seen as good rather
than anti-stable, upstreams started moving. That means a LONG support
release from some upstream players might be 18 months vs 4 years in the mid
2000s.

Those two assumptions not holding up are enough of a reason to recharter.

One thing I wished we had done early on was attract EPEL maintainers or
separate from Fedora where desired. I found that lots of people only wanted
to maintain packages in Fedora. They didn't care about EPEL at all. I found
that people who really cared about the EL stack, didn't care about Fedora,
but to help with EPEL, you had to be a Fedora person. I am not sure on the
status of all that any more (cause I'm delinquent and way less active than
I probably should be), but if that's still the case, could that be fixed in
any way? Now that CentOS is under the RH umbrella it seems like there could
be an enterprise community contributor worflow/org/group thing. (Apologies
if there already is, again, I'm just popping my head back up after a while
away).


> <snip>
>


> But by 2013, virtually all Red Hat major accounts (at least all I was
> exposed to) _outlawed_ EPEL from being enabled at all, because of the
> endless conflicts with countless, various Red Hat products.
>
> So ... today, in 2016, it doesn't really matter.  Back in 2012, I was
> more worried about EPEL becoming something customers cannot enable.
> But that's now the reality.
>
> FWIW, I haven't seen this reaction, but a few anecdotes are also not
data.  I do think as the OS has become more commoditized and the layered
products have become the differentiator, this is more of a truism though,
and should be planned for. Most people I see now mirror parts of EPEL and
their own packages and other stuff and slam that all together into their
package sets.
_______________________________________________
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Reply via email to