On 11/04/2017 10:35 AM, Felix Schwarz wrote:
> 
> Am 03.11.2017 um 16:09 schrieb Stephen John Smoogen:
>> OK how can we better explain this in the future?
> 
> I don't think there is an easy solution with "just another mail to -announce"
> or so. Personally I don't find it really practical scanning a mailing list for
> relevant packages (and filtering all the messages which might be "noise" to me
> because I don't use these packages).

Agreed. I don't know if anyone else does this, but I subscribe to all of
the RSS feeds I can find on relevant topics. I poll them from my
Nextcloud RSS (to distribute the list to all my devices) then combined
with Liferea RSS feed reader (to keep a long search able history on my
primary desktop) gives me quite a bit of information.

I don't necessarily "care" that $DISTRO just released $NEW_PACKAGE or
deprecated $OLD_PACKAGE or release security patch for $PACKAGE, but it
gives me 1) a notification that *something* did change 2) that quick
search-able history when I suspect a package update just broke something
as my first go-to.

Unfortunately, the RSS feed that I was subscribed to for epel-announce
was just a scraper for the online archives which broke some time back.
To my knowledge (I would LOVE for someone to prove me wrong, but I just
looked again), EPEL does not have a RSS feed for this information
(though they DO have an RSS for wiki changes...but that's not something
I'm interested in :). I know Fedora[1] provides tons of RSS feeds but I
don't know how difficult it would be for EPEL to piggy-back off of them.

[1] Just one example: http://fedoraplanet.org/infofeed/

> 
> One important thing why I'm using Fedora (and not a rolling release distro) is
> that I want to have specific points in time when I can prepare for bigger
> fallout (Fedora releases). This means EPEL could aim to introduce actual
> "releases" (e.g. every 3 months or so).
> 
> Breaking updates would be pushed only at these times (unless there is a
> *really* good reason). This could involve also writing some release notes
> (e.g. the packager could tick a box "breaking update" and submit a note which
> is then added to the release notes).

In theory, I agree. However, that seems like a lot more work and I
honestly don't know if there are enough EPEL users who would appreciate
the feature to justify the amount of work that would require. It's an
interesting discussion point but in my (self-admittedly small
understanding of EPEL behind-the-scenes) view is that is a BIG ask with
potentially small impact. Again, I'd love to be proven wrong on this
which is why it might make for interesting discussion. :-)

> Currently EPEL is basically a "rolling release" distro which is probably the
> opposite of what RHEL/CentOS users are looking for.

To some extent. I can pull together a list of a dozen packages I *wish*
would be updated in EPEL. I can also pull together a list of packages
that I'm dreading when they get updated. For me and my small use case,
it's about 95% where I need it to be. For the 2% where I really need
newer, IUS covers that quite well.

> 
> The second big thing to me is that the "support policy" for each package is
> not easily discoverable (as far as I know). I suspect it might be especially
> helpful if there are some kind of "categories" so you grasp the policy very
> quickly (e.g. "inline with upstream stable", "switch when package is EOLd
> upstream", "2 years", "just a few months").

I agree with this. I have to do it so rarely that it takes me ages of
digging around in the Fedora koji system to figure out package
information. There's a lot of good information in there, but sometimes
it takes a TON of effort to dig it out.

> So in essence I think EPEL needs to stop pretending it can support packages
> for a full RHEL lifecycle (= no need for "releases") and unfortunately some
> extra tooling is required.

Again, this is my limited view but I can't really recall anyone from
EPEL leadership/developers who have claimed that. However, I can pretty
easily dig up several responses similar to "EPEL is a best effort from
volunteers to provide missing pieces to USV".

Honestly, I wish USV had a mechanism in place that allowed more
community feedback into what packages were maintained up stream.

Here's one example. I personally know 5 admins from Red Hat who run htop
on the many corporate Red Hat servers they manage. They pull from EPEL.
Their internal voice counts, but not as high as customers. That same
htop from EPEL package is installed on nearly every one of my CentOS and
Scientific Linux friends servers. At least two of that group have server
counts in the multiple 1000's. Because they are not RH customers, their
voice counts for very little. I, as RH customer (+Scientific Linux),
supposedly have a "louder" voice in my vote on having htop be package in
the default repos, but every time I pester them about it I basically get
brushed off saying that it isn't a "high demand package". Grrrrrr...I
know for a fact that at least a dozen other RH customers claim they've
asked for htop. It would be nice if there was a touch more transparency
in how a package can move from EPEL into USV support. Then it would
matter less that EPEL is moving packages along at faster rate as EPEL
could focus on those packages that /need/ to move at a faster rate and
let USV handle the common packages as well as those that need stability.

Any way. My 2 cents. :-)
~Stack~

P.S. Seriously, if you know a good RSS feed for following EPEL
announcement, please let me know. I've not figured out how to get an RSS
out of Fedora Hyperkitty yet. :-)


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Reply via email to