Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).

--
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux