On Mon, Dec 11, 2023 at 08:28:31AM -0500, Stephen Gallagher wrote: > > While I generally agree that a merge request is a more polite and > elegant solution, if a package is listed as FTBFS (having had a bug > automatically opened) and some reasonable amount of time (two, three > weeks?) has passed, then I think it's perfectly reasonable to assume > that the maintainer is vacant (either entirely or because they lack > the available time to deal with it at this point). In that case, I > don't see it as a problem to jump in and fix the package as a > provenpackager if the fix is relatively minor (yes, this is > subjective). I'd hesitate at rebasing to a new version, but if the > issue is that a dependency changed its name or the newest gcc made a > warning into an error, I think that's a perfectly acceptable fix to > make. The ideal case is for it to go through a merge request, but if > the package happens to be blocking other work, I think expediency is > completely warranted. I think the key here is that everyone needs to make sure and communicate with others. If there's a FTBFS bugzilla bug and you are working on a good fix with upstream, say so in the bug. If you are a provenpackager and you need to fix a FTBFS quickly for some reason, look at the bug, if you see the maintainer(s) mentioning they were working on it, ask in bug if you could push a quick fix now and explain why you need it. Use good commit messages. "Fix FTBFS" is not a good commit message, "Fix FTBFS with a quick fix to xyz because we need to rebuild the package for rebuild of package X, this may not be the final fix". Use the packagename-maintainers aliases and notify when you are doing things. Even if everyone doesn't have time to react to communications, just making the effort helps everyone know what happened and whats going on. 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
