On 11/04/2017 08: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). > > 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. We have talked about doing this kind of thing in the past, but... it's a ton more work (you have to have releng folks do a bunch of work every 3 months or whatever) and we could never agree on the timing. Is it just randomly every 3 months? everytime a new RHEL minor is out? Every time a new CentOS minor is out? > 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"). While all the modularity work in Fedora is all early days and up in the air, this may be something we get "for free" from it. Branches now have a SLA in Fedora, we should be able to leverage that and expose it better to users. Of course everything may change with modules, it's really early to tell. We may be able to make different modules with different SLAs... kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx