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). 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). Currently EPEL is basically a "rolling release" distro which is probably the opposite of what RHEL/CentOS users are looking for. 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"). 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. Felix _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
