On 17 May 2018 at 15:31, Matthew Miller <mat...@fedoraproject.org> wrote:
> On Tue, May 15, 2018 at 03:06:43PM -0400, Stephen John Smoogen wrote:
>> 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
> 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.
>> 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
> Fedora Project Leader
> epel-devel mailing list -- email@example.com
> To unsubscribe send an email to epel-devel-le...@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:
Stephen J Smoogen.
epel-devel mailing list -- firstname.lastname@example.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines