+1

Just fyi, I would also like to rename f26-modularity to module-bootstrap-f26 to make the purpose of this tag clear, but this is something we have to do in sync with change in PDC.

Discussed here: https://meetbot.fedoraproject.org/fedora-meeting-2/2017-05-15/releng.2017-05-15-14.31.html

For docs on modularity, see https://docs.pagure.org/modularity/

The original MBS doc is here: https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/MBS

I'm not quite understanding the requests for documentation here. It feels very procedural, as if we are doing a strict waterfall methodology with rel-eng signoff required upfront — or else randomly gating things at the end. Rel-eng is obviously a stakeholder, but that heavyweight process doesn't feel right for Fedora.

I see that tags like f26-gnomeor f27-ocaml are generally created with very little effort; maybe a few questions about timeframe, but no cross-examination about the need for OCAML in Fedora at all or anything like that. Can't this be that easy — or, easier, since Modularity is a Council objective?

Okay, we now have a draft of the Host and Platform Fedora 27 Change Proposal. The Release Engineering review is tracked under #6815.

The Host and Platform wiki page describes the new concept, how it differs from Base Runtime and what the Bootstrap module is used for.

I'll just reiterate what's been said already -- here, during the meetings or our last week's call:

• I would like to have a new tag created; it should be named module-bootstrap-master to follow the naming scheme MBS uses
• this tag should inherit from module-package-list
• we'll maintain its content ourselves, tagging and untagging builds as we attempt to stabilize the buildroot; getting an empty tag would be perfectly fine and even preferred at this point -- it doesn't need to be a copy of f26-modularity
• this is a development tag but it's not the same as traditional Rawhide; while we intend to base our initial content by pointing our depsolving scripts at Rawhide, the module won't be following it automatically until we get it to a stable state we can later use as a reference point
• we'll probably need to tag/untag secure boot packages sooner or later; this can be done through filing additional tickets or through granting certain people (e.g. me) the right privileges, which I'll leave to you to decide

Thanks in advance.

We have created a module-bootstrap-rawhide tag that inherits from module-package-list, there is currently no packages tagged in at all

Thank you!

Ah, it's rawhide, not master... well, that's okay.

Please, tag the following secure boot packages into the new tag: releng#6823