1 |
> On 28 Mar 2022, at 12:13, Fabian Groffen <grobian@g.o> wrote: |
2 |
> |
3 |
> Hi, |
4 |
> |
5 |
> On 28-03-2022 13:05:03 +0200, Thomas Bracht Laumann Jespersen wrote: |
6 |
>> Hi! |
7 |
>> |
8 |
>> I've been working on a new section in the devmanual regarding conditional |
9 |
>> patching. In a PR [0] Sam suggested adding a section to clarify that conditional |
10 |
>> patching should be avoided, because it can quickly become a maintenance and |
11 |
>> testing burden. |
12 |
>> |
13 |
>> The devmanual PR is here: [1] |
14 |
>> |
15 |
>> Ulrich points out that conditional patching is actually suggested elsewhere, and |
16 |
>> that actively discouraging conditional patching is a policy change, which should |
17 |
>> be brought up on this list. So this is what I'm doing now. He also pointed out a |
18 |
>> comment in eutils.eclass re [2] (the comment now lives in epatch.eclass). |
19 |
>> |
20 |
|
21 |
As I say below, I somewhat think this is already de-facto policy to avoid. But |
22 |
having the discussion is not a bad thing. |
23 |
|
24 |
>> [snip] |
25 |
>> |
26 |
>> I think my question to this list is: Should it be policy that conditional |
27 |
>> patching is to be avoided? |
28 |
> |
29 |
> We really don't want conditional patches, but I from my experience |
30 |
> reality is that sometimes you have to. Therefore this should remain |
31 |
> possible. I have no problems with highly discouraging conditional |
32 |
> patching. |
33 |
|
34 |
I'm not suggesting banning them -- just codifying that they're |
35 |
discouraged unless unavoidable, which is what we "soft advise" |
36 |
right now anyway in both proxy-maint reviews but in general |
37 |
culture like mentoring. |
38 |
|
39 |
> |
40 |
> About your other points, I think they are kind of debatable. Gentoo |
41 |
> wants to be close to upstream, but with your set of rules, one can't |
42 |
> e.g. add hpn patches to ssh, which would be really silly, as the point |
43 |
> of Gentoo is that since you build from source, you can actually apply |
44 |
> such patches, conditionally if they don't have a means to be disabled. |
45 |
|
46 |
OpenSSH is actually a fantastic example of why it's a bad idea but |
47 |
the maintainers choose to live with the compromises (which is fine). |
48 |
|
49 |
I say "bad idea" because it leads to poor UX. We have to avoid |
50 |
doing bumps until the patches are out or live with pkg_setup die()s |
51 |
when they're not yet available. |
52 |
|
53 |
And then we get bugs filed for it. |
54 |
|
55 |
(This isn't a criticism of the OpenSSH maintainers in Gentoo, it's |
56 |
a special case for sure, but it's a great example of why we shouldn't |
57 |
be doing it en-masse unless we must.) |
58 |
|
59 |
> |
60 |
> In other words, I think the gist of your points is to be in an ideal |
61 |
> world, but unfortunately reality is far from it. That said, repeating |
62 |
> myself, nothing wrong with discouraging quick 'n' dirty, for as long as |
63 |
> it remains a big fat warning and advice. |
64 |
> |
65 |
|
66 |
Yep, the plan for this is big fat warning & advice. Not unconditionally |
67 |
banning condiitonal patching. |
68 |
|
69 |
> My €0.02 |
70 |
|
71 |
Appreciated as ever -- especially given you work in interesting |
72 |
corners like Prefix and now increasingly musl (yay!) |
73 |
|
74 |
Indeed, this is part of why we can't really ban it absolutely (not |
75 |
that I'm advocating for that anyway) -- for prefix and musl, while |
76 |
we want upstreamable patches, it's not always easy. |
77 |
|
78 |
Especially for more stale components of the toolchain or system |
79 |
which are critical but upstreaming is not feasible due to inactivity or |
80 |
whatever. |
81 |
|
82 |
> Fabian |
83 |
> |
84 |
>> [0]: https://github.com/gentoo/gentoo/pull/24709#discussion_r832361402 |
85 |
>> [1]: https://github.com/gentoo/devmanual/pull/281 |
86 |
>> [2]: https://gitweb.gentoo.org/archive/repo/gentoo-2.git/tree/eclass/eutils.eclass?id=50e8beda904760c773e5c67fdfe8242255e13495#n175 |
87 |
>> |
88 |
> |
89 |
|
90 |
Best, |
91 |
sam |