Re: git: b68bef1f6425 - main - x11-wm/kwinft: unbreak build after 5d998836b36f
Date: Wed, 10 Nov 2021 23:15:03 UTC
Fernando Apesteguía <fernando.apesteguia@gmail.com> writes: > On Wed, Nov 10, 2021 at 1:41 PM Jan Beich <jbeich@freebsd.org> wrote: > >> >> Baptiste Daroussin <bapt@FreeBSD.org> writes: >> >> > On Wed, Nov 10, 2021 at 10:58:46AM +0000, Jan Beich wrote: >> > >> >> The branch main has been updated by jbeich: >> >> >> >> URL: https://cgit.FreeBSD.org/ports/commit/?id=b68bef1f6425117cd0d0d95626178db4c4fb3073 >> >> >> >> commit b68bef1f6425117cd0d0d95626178db4c4fb3073 >> >> Author: Jan Beich <jbeich@FreeBSD.org> >> >> AuthorDate: 2021-11-10 09:24:08 +0000 >> >> Commit: Jan Beich <jbeich@FreeBSD.org> >> >> CommitDate: 2021-11-10 10:58:09 +0000 >> >> >> >> x11-wm/kwinft: unbreak build after 5d998836b36f >> >> >> >> input/filters/window_selector.cpp:19:10: fatal error: 'linux/input.h' file not found >> >> #include <linux/input.h> >> >> ^~~~~~~~~~~~~~~ >> >> >> >> Pointy hat to: manu >> > >> > To be honnest I am puzzled about this pointy hat, while manu should have tested the >> > reverse dependencies of mtdev to make sure noone wrongly took its run >> > dependencies as granted as its own build dependencies and fix them upfront, >> > On the otherside, all the ports should be explicit about ALL their direct build >> > dependencies, and not expect another port to provide them. >> >> According to FreshPorts devel/libmtdev has 3 consumers: >> >> - x11/libinput has 22 consumers >> - x11-drivers/xf86-input-evdev has 1 consumer >> - x11-toolkits/qt5-gui has 1033 consumers >> >> Testing all qt5-gui consumers locally is challenging. Some of those may >> have consumers of their own. >> >> > Meaning the said ports were buggy in the first place. >> >> It was unexpected/disrupting. And without exp-run it's unknown how many >> more ports may need to be fixed (I only regularly test mine). Besides, >> destabilizing the tree too much degrades the quality of exp-runs that >> maybe ongoing in parallel for unrelated changes. >> >> > >> > This is one of the reason the Pointy hat culture has been removed from the ports >> > land in general in favor or at best only accepting self pointy hatting. >> > >> > So as a community if we could avoid finger pointing at others. >> >> Agree, pointy hats can discourage new contributors, drive away existing >> ones due to exhausting negativity or attract trolls. This was mostly a >> silly/petty attempt to grab (mainly manu's) attention. > > In order to do that, we could use the Fixed: field in the commit > template. After all, that is what it is for. > Extra bonus if there is a hook that sends a private mail to the > committer whose commit is being fixed. I've been using "after <revision>" for ~6 years, since e771b80b60f2. "Fixes" field is harder to notice when visually scanning new email, "git log --oneline" or through GitHub/GitLab/Gitea web frontend. Regression fixes are similar to security fixes, so quickly finding candidates for "git cherry-pick" helps. See also https://www.conventionalcommits.org/ for an idea how to encode more information into Summary. Unfortunately, it doesn't standardize types of fixes (security, regression, crash, data corruption).