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) > > > > > # 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? > > > > > # 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
