On 17 May 2018 at 15:31, Matthew Miller <mattdm(a)fedoraproject.org> 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(a)fedoraproject.org>
Fedora Project Leader
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproj...
--
Stephen J Smoogen.