On 25. 01. 21 19:29, Zbigniew Jędrzejewski-Szmek wrote:
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.
Right. I was talking about changes that introduce a FTBFS.
Obviously, if the package already fails to build, try pushing tested changes as
well, but anything that doesn't make it intentioanlly worse is OK.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
