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