On Fri, May 18, 2018 at 9:42 AM Ralph Bean <rbean@xxxxxxxxxx> wrote:
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.
The above was a slight mischaracterization. The modularity-wg provides requirements to the Factory-2 team for things needed to support modularity. We then, sometimes, build things for the Factory-2 team. However, in order to avoid x-ing wires or making mistakes, we (modularity-wg) do not provide schedules/timelines/etc for the work (even if we think we know them).
So, in the general sense, of course we are aware of the things we are asking for but we leave it to F2, Fedora Infra, and releng for when we are going to get them or coordinating how they will be released. The last thing we need is the modularity-wg promising, for example, ursa-major to fedora-infra when F2 has never even heard the decision.
>
> > 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.
And, to be clear, that was my original suggestion :). I think it is definitely necessary for both teams to have reps there. So, +1? :)
langdon
_______________________________________________
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/
_______________________________________________ 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/BDRAQCOTVK2QFVV7RZO7IX75V5SVXLHY/
