On Thu, Sep 5, 2019 at 4:56 AM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > As we plan EPEL 8.1 with support for Modularity/Application Streams, > we will undoubtedly encounter numerous tricky questions that warrant > public input. The first of these is this: where do modules fit into > EPEL 8 Playground? > > > I see three possibilities for how this can be done: > > 1) We create two "platform" modules: "platform:el8" and > "platform:el8-playground" and use module stream expansion (MSE) or > separate branches to build twice, once for each platform. The > buildroot for each of these will be the latest set of tags composed > for the stable repo + default module streams (for el8) and the > playground repo + default module streams (for el8-playground), > respectively, plus whatever module dependencies are needed. Builds > against el8 will be tagged as candidates and must go through > updates-testing. Builds against el8-playground will be tagged directly > into the Modular Playground compose. > > Pros: This is closest to what we are doing for regular packages. > Allows us to specialize the builds for dependencies available only in > playground. > Cons: Uses twice the build resources. Requires a compose for the > Modular Playground. > > > 2) We create only one platform module: "platform:el8" using the el8 > stable tag plus the Modular stable tag's default streams. We build the > module stream a single time. Builds tagged with > epel8-modular-candidate will be automatically tagged to > epel8-modular-playground. For them to get to epel-testing and later to > epel8-modular-stable, they must be submitted to Bodhi. > > Pros: Builds use less resources. Composes for Modular Playground will > be able to hardlink much of their content, so disk space will be > reduced. > Cons: Requires a separate compose for Modular Playground. Cannot > provide specialized builds for deps available only in playground. > > > 3) We create only one platform module: "platform:el8" using the el8 > stable tag plus the Modular stable tag's default streams. We build the > module stream a single time. All builds go through Bodhi. Users of > epel8-playground are encouraged to enable the > epel8-modular-updates-testing repo. > > Pros: Requires the fewest resources. Needs only the Modular compose. > Cons: Documenting the usage might be confusing. Modular Playground > doesn't get all builds like the epel8-playground does, only the ones > submitted to Bodhi (might impact users who intend to have "build for > playground" as part of their CI/nightly build system). > I prefer 1. Reasons: Right now, most of the packages I am building (KDE) are in playground only. I really like that it is separate. I also like that for my non-playground packages, I can ignore playground, yet playground get's the benefit from my work. Option 1 looks like it is closes to my current scenario, just in modular form. Option 2, doesn't look that bad to me. I'm a little fuzzy on some of the details, but it seems like playground should still get most of the benefits of playground, but just that if you are dealing with modules, you start with non-playground. Option 3, I don't like. -testing should have nothing to do with -playground. I'm not against the -playground packages going through bodhi, but I am against modules going through bodhi, but regular rpm's not going through it. Troy Dawson _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
