On 17 May 2018 at 15:31, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > On Tue, May 15, 2018 at 03:06:43PM -0400, Stephen John Smoogen wrote: >> Modules > [...] >> EPIC-next >> >> The tooling for modules can match how Fedora approaches it. This >> means that rules for module inclusion will be similar to package >> inclusion. EPIC-next modules must not replace/conflict with CentOS >> modules. They may use their own namespace to offer newer versions >> than what is offered and those modules may be removed in the next >> minor release if CentOS offers them then. > > I think we should do this part differently. Each Fedora module has its > own lifespan, separate from that of the base OS. It automatically gets > built across all currently-supported base OSes. That way, I can > maintain, say, "calc-2.x" in just one stream (where stream = git > branch), and it automatically gets built everywhere. Rather than having > EPIC modules be entirely separate, I'd like to just include them in > this: by default, build all modules against both the Fedora _and_ EL > bases. > > This has a further implication: these modules _may_ replace or conflict > with CentOS (and possibly RHEL) modules. But you'd have to opt-in to > those streams explicitly to do so. With non-modular Yum/DNF, having some > packages update base software would be horrific because enabling the > repo and running `yum update` would do who-knows-what. But with > modules, that's not a problem. > I have been worried about a negative feedback loop here on packagers. This is a new technology and packagers aren't usually people who care about EPEL. Having them to deal with multiple OS's they don't use makes it more likely they don't want to put stuff in modules in the first place. I would prefer to be looser on the uptake of modules to get people comfortable with them in Fedora first. I also don't expect a large demand for modules in EPIC. Most enterprise system administrators are from Missouri. They are going to want you to prove that it isn't going to eat their systems before they are going to want to try it in development. They are also going to want to make sure that it is still being developed in F3X versus something that just showed up in F28. As 2-4 releases show up with modules in them, then it is going to be wanted more in EPIC and by then the procedures and plans for how they are done in Fedora should be 'solid' enough for the enterprise admin. > >> EPIC >> Extra Packages Inter Community. > > Extra Packages for Impassioned Community? > Extra Packages Included by Community? > Extra Packages Introduced by Community? > Extra Packages Including Community? > Extra Packages for Innnnnterprise Community? (Or "EPEC"?) > Extra Packages for Introverted Communities > > > -- > Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> > Fedora Project Leader > _______________________________________________ > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx/message/PHQUXTILYCJYVZTEZMNMLDTQDIZDUH6V/ -- Stephen J Smoogen. _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx/message/CL7NDRTEZXK3V37LG3737LFSPA6X6U7Z/
