On Tue, May 15, 2018 at 05:01:56PM -0700, Kevin Fenzi wrote: > On 05/15/2018 08:08 AM, Randy Barlow wrote: > > Greetings! > > > > At the hackathon we did recently, we talked about the need for one of us > > to attend the Modularity WG meetings so we could be more aware of what > > work is coming our way before it's a surprise, and I volunteered to be > > that person. > > > > For $reasons, today was the first of the WG meetings I was able to > > attend. There were two items of interest: > > > > > > New service > > =========== > > > > I learned that Factory 2 is developing a new service called Ursa Major. > > I gathered that its mission is to make it so that RPMs that depend on > > modules can get those modules pulled into their buildroot. > > > > Ralph, is the above correct? If so, what time frame do you anticipate us > > needing to get this service deployed to infrastructure? It is kinda correct. We developed ursa-major specifically not-for-Fedora... and now that it exists, folks are asking if we can also use it in Fedora. I have nothing in my current plans (up through F29) to do anything with ursa-major in Fedora.. but, since people have started asking for it I guess we should talk about it. Can I explain it? First, some context on the name: rpms in a module are called "modular" rpms. RPMS not in a module are "bare". Sync "bare" is a homophone with "bear", and "ursine" means relating to or resembling bears, we jokingly call bare rpms "ursine" rpms...... So ursa-major does something with ursine rpms (bare, non-modular rpms). The problem is how to transition from our current mostly-bare-rpms-with-a-few-modules state to a future still-some-bare-rpms-but-with-many-more-modules state. There are some packages in Fedora that make sense to always be in the non-modular core. There are other packages in Fedora that make sense to modularize, of which we should provide multiple parallel versions. There is an intersection between these two groups that ursa-major tries to address: packages which should be modularized, but which are needed *in the buildroot for the non-modular core*. These are things like higher level language stacks which are used to build the docs or run the %check tests of lower level components -- all at build time. The flow: - ursa-major is a script that runs on message bus trigger. - It has a config that defines some set of module streams that should be tagged into the core buildroot. Releng maintains this config, as it affects the whole distro. - When ursa-major fires, it takes a new module (or a module that has passed testing, or which has gone stable) and adds its tag to the tag inheritance of the base build tag - say, the f30-build tag. - Then, when new ursine rpms are built in the traditional way, they have some subset of what would otherwise be modular rpms available. To say again, I have no plans to seek to deploy this atm, but people have started asking for it... so, maybe we need some solution to the problem. It could be this tool or some other tool -- perhaps as a part of Bodhi's workflow: as modules get promoted, a select releng-maintained subset could be tagged into the base tag. > > Meetings > > ======== > > > > The modularity WG suggested that it was probably not that beneficial for > > me to attend their meetings as an infra liason, as they are not actually > > particularly familiar with the infrastructure side of things. They > > suggested instead that we interface with Factory 2. > > Makes sense. > > > A suggestion was made that perhaps we could have an agenda item on *our* > > meeting, perhaps once a month, where we invite modularity WG and factory > > 2 to talk with us about what is coming our way, or about issues that > > need dealing with. I thought this was a fine suggestion, so I wanted to > > ask you all what you thought about it? > > I think thats a fine idea, but do we know who we can contact to invite? > And will we remember? > > Thanks for going to the meeting and keeping us informed! I can come, and bring some others. :) If it is recurring, then a calendar thingie will help make us not forget. I'd say let's not rely only on my team (Factory2) as an intermediary between you guys and the modularity-wg. Let's invite them too.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-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/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx/message/JZMPGE2VMBHDO4D6SC4YTRSYNQYZOT63/
