On Mon, Jan 25, 2021 at 07:19:45PM +0100, Miro Hrončok wrote: > On 25. 01. 21 19:03, Zbigniew Jędrzejewski-Szmek wrote: > >On Mon, Jan 25, 2021 at 03:59:43PM +0100, Miro Hrončok wrote: > >>1. Packagers MUST NOT push changes that are not considered ready to > >>be built and shipped at the time of the push. Using Pull Requests > >>(clearly marked as not ready to be merged) is a better place to > >>present/save changes that are not ready yet. > >> > >>2. Packagers SHOULD preemptively check if the changes they intend to > >>push work. At least checking if the intended change builds and the > >>package installs with it is strongly recommended. In cases where the > >>check is skipped for time reasons (e.g. when a testing build takes > >>several hours and the changes are urgent), packagers SHOULD be ready > >>to fix the build/installation failure in timely manner after it is > >>discovered by the actual build. > > > >I agree with the general idea. But I think it is important that the > >second part is SHOULD (as you wrote), and the text should make it clear > >that there may be good reasons to push commits which haven't been > >preemptively tested. > > > >For example: packages which take a long time to build, and are known to > >pseudorandomly fail on less-used architectures. Doing a 10h scratch build > >just to have it pass, and then the real build fail is common. And even > >if it fails, I wouldn't want to be on the hook to fix this "in a timely > >manner". I'll certainly get to it at some point, but it may be a few > >weeks before I have the few hours necessary to dig into some complicated > >test failures. > > I agree that there are cases where doing a 10h scratch build is not > desired. However I'd rather if the update is delayed by 10h than > wasting many other packagers time. If you can only afford to come > and fix an introduced failure in a few weeks, it should IMHO not > acceptable to push and walk away (unless you are prepared to revert > the commit). But a revert might not be appropriate at all. The failure might be caused by a different bug or some issue in with a dependency, and this cannot be known without some investigation. If we consider packages with are *already* FTBFS — pushing changes which may fix some stuff but don't allow the package to build does not make the problem for pps any better or worse. So I think already-FTBFS packages should be excluded from this policy. Zbyszek _______________________________________________ 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
