> On 28 Mar 2022, at 12:13, Fabian Groffen <grob...@gentoo.org> wrote: > > Hi, > > On 28-03-2022 13:05:03 +0200, Thomas Bracht Laumann Jespersen wrote: >> Hi! >> >> I've been working on a new section in the devmanual regarding conditional >> patching. In a PR [0] Sam suggested adding a section to clarify that >> conditional >> patching should be avoided, because it can quickly become a maintenance and >> testing burden. >> >> The devmanual PR is here: [1] >> >> Ulrich points out that conditional patching is actually suggested elsewhere, >> and >> that actively discouraging conditional patching is a policy change, which >> should >> be brought up on this list. So this is what I'm doing now. He also pointed >> out a >> comment in eutils.eclass re [2] (the comment now lives in epatch.eclass). >>
As I say below, I somewhat think this is already de-facto policy to avoid. But having the discussion is not a bad thing. >> [snip] >> >> I think my question to this list is: Should it be policy that conditional >> patching is to be avoided? > > We really don't want conditional patches, but I from my experience > reality is that sometimes you have to. Therefore this should remain > possible. I have no problems with highly discouraging conditional > patching. I'm not suggesting banning them -- just codifying that they're discouraged unless unavoidable, which is what we "soft advise" right now anyway in both proxy-maint reviews but in general culture like mentoring. > > About your other points, I think they are kind of debatable. Gentoo > wants to be close to upstream, but with your set of rules, one can't > e.g. add hpn patches to ssh, which would be really silly, as the point > of Gentoo is that since you build from source, you can actually apply > such patches, conditionally if they don't have a means to be disabled. OpenSSH is actually a fantastic example of why it's a bad idea but the maintainers choose to live with the compromises (which is fine). I say "bad idea" because it leads to poor UX. We have to avoid doing bumps until the patches are out or live with pkg_setup die()s when they're not yet available. And then we get bugs filed for it. (This isn't a criticism of the OpenSSH maintainers in Gentoo, it's a special case for sure, but it's a great example of why we shouldn't be doing it en-masse unless we must.) > > In other words, I think the gist of your points is to be in an ideal > world, but unfortunately reality is far from it. That said, repeating > myself, nothing wrong with discouraging quick 'n' dirty, for as long as > it remains a big fat warning and advice. > Yep, the plan for this is big fat warning & advice. Not unconditionally banning condiitonal patching. > My €0.02 Appreciated as ever -- especially given you work in interesting corners like Prefix and now increasingly musl (yay!) Indeed, this is part of why we can't really ban it absolutely (not that I'm advocating for that anyway) -- for prefix and musl, while we want upstreamable patches, it's not always easy. Especially for more stale components of the toolchain or system which are critical but upstreaming is not feasible due to inactivity or whatever. > Fabian > >> [0]: https://github.com/gentoo/gentoo/pull/24709#discussion_r832361402 >> [1]: https://github.com/gentoo/devmanual/pull/281 >> [2]: >> https://gitweb.gentoo.org/archive/repo/gentoo-2.git/tree/eclass/eutils.eclass?id=50e8beda904760c773e5c67fdfe8242255e13495#n175 >> > Best, sam
signature.asc
Description: Message signed with OpenPGP
