I think this will be my last reply on the topic...I think people know my view and Kevin's here (but if other folks have more questions, happy to answer them).
On Sat, Feb 12, 2022 at 08:09:34PM +0100, Kevin Kofler via devel wrote: > Kevin Fenzi wrote: > > As a release engineer trying to get a rawhide compose, I do find this a > > big deal. (Another f37 compose just failed because of this issue). > > Well, as I already pointed out more than once, the real issue there is that > the Rawhide compose fails due to a broken dependency. This used not to be > the case. If a deliverable fails to compose, then it will be missing for one > day (or ideally, just keep the last one that built on the mirrors!). If it > is release-blocking, it needs to be fixed before the release. Not sooner. But thats way too late. Say you are working on a change, you get it all landed, and... someone breaks deps that causes images to not compose. You can't wait until release to get that fixed and see that it breaks a bunch of your work that you now need to fix. > This is how things used to work in the past (without the "or ideally" part, > that is just my improvement suggestion that was never implemented) and it is > why we were able to work much better with broken dependencies in Rawhide > back then than now. I disagree. I think rawhide is _more_ usefull now that it's at least Alpha quality all the time instead of broken for long periods. > > > Long ago we worked that way. Back when there were few packages and few > > maintainers. > > The number of packages increases constantly, but the order of magnitude was > not that different. What really made the difference was that the composes > did not fail. Instead, they would succeed and we would automatically get a > list of broken dependencies sent to the devel list (and then provenpackagers > like Alex Lancaster and me tried to mass-fix them, and IMHO did a very good > job at it, until, in lieu of a "thank you", we were told not to because it > "masks the issue of unmaintained packages"… that was the point at which > broken dependencies started to accumulate, creating the demand for gating). I recall things differently. :) I fixed many a broken dep in the day too... but it's much more effective for everyone to not have them in the first place and it doesn't even require that much more work. Making a side tag takes 10 seconds. Sure, you may have to wait until deps are all sorted before merging, but that saves everyone a vast amount of time. Perhaps you and Alex would be willing to volenteer to help maintainers finish up builds in side tags when asked? I know a number of times people mention on list that they would like help with builds in sidetags. kevin
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
