On 25/01/21 13:42 -0500, Stephen John Smoogen wrote:
On Mon, 25 Jan 2021 at 13:30, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>
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 .]
Surely it would be better to fork the repo at src.fedoraproject.org
into your own user namespace, add that as a remote, and push the
temp-branch there instead. You can have whatever branches you want at
src.fedoraproject.org/$USER/rpms/foo so there's no good reason to push
unfinished work to a branch under /rpms/foo
My approach is to just use a local git branch for work in progress,
and if I want an "off site" backup, or to share it with somebody else,
then I push to a fork under src/fedoraproject.org/jwakely/rpms
_______________________________________________
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
