On Sat, Dec 5, 2020 at 7:46 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On Fri, Dec 04, 2020 at 10:23:08PM +0100, Petr Šabata wrote: > > On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > > > > > On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote: > > > > Also a couple of notes on modularity here: > > > > > > > > # By default, module stream name is derived from the branch name > > > > If we have any "master" modules, those will get unexpectedly renamed > > > > as soon as they get rebuilt. This might impact tagging or updates and > > > > cause confusion in general. We should check if there are any like that > > > > and decide on further steps. > > > > > > Good thing to check yes. I can try and do so. > > > > Thanks. > > hum, but I am not 100% sure what I am looking for. > modules with a master branch and no name defined? > What does the name being defined look like in the yaml file? Yes. You could also query MBS for stream=master and see if there's anything reasonably recent to narrow your search. But branches would be enough. In modulemd, stream name is defined as "stream: <streamname>". > > > > # Modules might be pulling components from their master branches to > > > > build Rawhide artifacts > > > > There are various use cases for this, too long to list. If the master > > > > ref is no longer available, these will not build. Modulemd files that > > > > pull components from master need to be updated after Phase 2. > > > > > > Yep. +1 > > > > Great, will you do that, too? > > There seems to be a bunch of them. ;( Many of those are definitely obsolete, though! > > > > # The modulemd component ref is optional and defaults to master > > > > Unless this got changed later, if the ref field is omitted, the value > > > > defaults to "master". This is part of the specification and is handled > > > > by libmodulemd. Not sure how to proceed here. > > > > > > Can we change the default? > > > > According to Vít that's already happened (for completely unrelated > > reasons), so we're good here. > > ok. > > > > > And besides modularity: > > > > > > > > There are people and teams who use bots to autobuild their upstream > > > > projects in Rawhide. If they have a bot account (and I hope they do), > > > > they should be notified to update their tooling. > > > > > > We don't have much tracking on bot accounts. People make them and sign > > > up for fas for them, etc. > > > > > > We can try and find things that are obvious, but we are likely to miss > > > some. We can definitely help people who notice breakage tho. > > > > Ah, I kinda expected these accounts to be clearly marked as being > > non-human. Oh well. > > > > Anyway, besides the magical module stream renames, all of this should > > continue to work fine if we get the symbolic refs, I think? > > Well, I am ok with a symbolic ref from main to/from rawhide, but I don't > like the idea of a master symbolic ref. It kind of defeats the purpose > of the entire thing. ;( Well, okay. If we get the master ref, I'm happy as that's mostly a no-op for me. If not, it implies a lot of downstream RHEL work we'll have to handle. Just let us all know in due time. P _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
