On Mon, 25 Jan 2021 at 13:30, Zbigniew Jędrzejewski-Szmek <zbys...@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.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
