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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
