On Tue, Dec 8, 2020 at 11:57 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On Mon, Dec 07, 2020 at 10:13:13PM +0100, Petr Šabata wrote: > > 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>". > > So, I looked back the last 3 months and I am pretty sure the only ones > are all flatpaks. (firefix, thunderbird, etc) https://mbs.fedoraproject.org/module-build-service/1/module-builds/?stream=master I can also see avocado:master built for f33 there on the first page. But it could also matter for flatpaks if the name is referenced in the build process. CC'ing Owen. > > > > > > # 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! > > Well, I checked out all the modules from rawhide. How can I tell they > are obsolete? Uh; I was fairly certain some of those were my dev modules from the Boltron era. If I recall correctly, Merlin was working on marking modules as obsolete at some point. Maybe we didn't actually run it all of them and they're being built automatically. We should review everything that's in Rawhide and obviously isn't supposed to be. CC'ing Merlin. P > > > > > > # 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. > > Well, I don't want to keep master around in any form... and yeah, I > realize there's going to be fallout. ;( > > kevin > _______________________________________________ > 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 _______________________________________________ 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
