On Mon, Jan 25, 2021 at 01:42:17PM -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 'temp-branch' is just an idea, right? Normally branches in dist-git are semi-permanent and require a releng ticket to be removed. > 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 Actually, for such tests a branch is not needed. I can do builds locally in mock or even koji --scratch from a real branch. Just don't push the commits to the dist-git remote. I have done this in the past when dealing with mass changes, and I don't think branches would make this any easier. (That's why I was talking about packages which take long enough to build to make scratch builds undesirable... If we can do a scratch build without too much hassle, let's just do that.) Zbyszek _______________________________________________ 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
