On Mon, 25 Jan 2021 at 13:30, Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> 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.


If this was some other code which was tied into some sort of continuous rebuild system, wouldn't the developer strategy be that you would push the changes to a branch which wasn't rebuilt, test that and then pull the fixes in. I am not talking about fork and pr.. I am just thinking branch and pull which should be scriptable in even a 10k package ownership method.

say something like

for X in packages
fedpkg temp-scratch -b scratch-fedora
fedpkg switch-branch scratch-fedora
sed 's/foo/bar/g' *.spec
# if possible if not you still can do stuff
fedpkg build-scratch
if $?
 echo yay
 fedpkg merge-scratch --delete-temp scratch-fedora '$target-branch'
 # this could attempt a merge and fail if not possible
 fedpkg build
else
 echo "oh noez.. manual work required"
 exit
fi
done

in the cases of just doing some late-night work you want to get somewhere but not your laptop
fedpkg temp-branch -b
fedpkg push
#next week
fedpkg build-scratch
fedpkg merge-scratch

[Not sure if the above is a workable idea but I figured an 'example' might help .]


--
Stephen J Smoogen.