1 |
Tom Wijsman wrote: |
2 |
> Greg KH wrote: |
3 |
> |
4 |
> > On Mon, Jul 01, 2013 at 09:25:42PM +0200, Tom Wijsman wrote: |
5 |
> > > On Mon, 1 Jul 2013 14:09:57 -0500 |
6 |
> > > Matthew Summers <quantumsummers@g.o> wrote: |
7 |
> > > > If the patchset patches the kernel's core, it doesn't matter what |
8 |
> > > > CONFIG_* option is set the core kernel code |
9 |
> > > > _has_now_been_changed_. This is the crux of the argument, I |
10 |
> > > > believe. AUFS simply being one example of this. I'm sure there |
11 |
> > > > are others. |
12 |
> > > |
13 |
> > > As per my response to that point, this statement is no longer true. |
14 |
> > > |
15 |
> > > Let me re-iterate it here: |
16 |
> > > |
17 |
> > > Earlier I mentioned "3) The patch should not affect the build by |
18 |
> > > default."; if it does, we have to adjust it to not do that, this is |
19 |
> > > something that can be easily scripted. |
20 |
|
21 |
If it does then it should never be applied, unless the user specifically |
22 |
asks for it, imo, and the resultant kernel is labelled -exp as you suggest. |
23 |
|
24 |
> It's just a matter of |
25 |
> > > embedding each + block in the diff with a config check and updating |
26 |
> > > the counts. |
27 |
> > |
28 |
> > Wonderful, now you are maintaining a patch that looks nothing like the |
29 |
> > one created by the original developers, nor tested by anyone else |
30 |
> > other than gentoo developers. |
31 |
> |
32 |
> I can convert the original developer's patch whenever he updates it; or |
33 |
> on top of that, write a script to generate the original patch back. |
34 |
|
35 |
Please, just keep a copy of the original patch as well as the modified |
36 |
output from the script, somewhere reasonable to you, if you are doing any |
37 |
editing. Traceability is essential here. Personally I think it ill-advised, |
38 |
and would prefer simply that the patch were not applied if the above process |
39 |
in your testing prior to usage, showed that it would affect other parts of |
40 |
the build inappropriately, even when configured off. Or it's known to do so, |
41 |
like aufs. |
42 |
|
43 |
Unless of course the user specifically requests it. This can be a simple |
44 |
variable with a list of required patches, or whatever. |
45 |
|
46 |
> > Playing fast-and-loose with kernel patches is a fun thing to do, but |
47 |
> > really, why? Users love doing this type of thing, but the |
48 |
> > interactions of different kernel patches with core subsystems is |
49 |
> > almost always a non-trivial thing. |
50 |
> |
51 |
> Our main intent is to provide them and deduplicate work; if users have |
52 |
> a problem with one of the patches and it isn't clear to us, we can |
53 |
> forward them to the authors. Nothing in this proposal inherits that we |
54 |
> must support the patches; especially not, since they are "experimental". |
55 |
|
56 |
I agree that users love doing this sort of thing, and that it makes sense |
57 |
to provide a standard opt-in mechanism, so that it's immediately obvious |
58 |
in bug-reports that a custom, non-upstream, kernel patch is in use. |
59 |
|
60 |
> > I'm not saying not to do this, but consider this a friendly warning |
61 |
> > that this is going to be a MAJOR pain to maintain and debug over the |
62 |
> > long-run. |
63 |
> |
64 |
> Maybe, maybe not; plan is to do a slow start, congestion avoidance. :) |
65 |
> |
66 |
> > But hey, what do I know? It's not like I've ever done this before and |
67 |
> > had the experience of the resulting fall-out that took years to |
68 |
> > recover from on user's production systems, causing a number of |
69 |
> > enterprise Linux companies to swear that they would never do this |
70 |
> > type of thing again... |
71 |
|
72 |
As you said, users love doing this sort of thing, so it's happening under |
73 |
our noses in any case; that's the nature of a source distribution. In such |
74 |
a case it makes sense to have the info in a bug-report from the beginning. |
75 |
|
76 |
> I covered this in the conditions as well as the F.A.Q.; feel free to |
77 |
> read about it again, this does not affect them unless they explicitly |
78 |
> want them to enable CONFIG_GENTOO_EXPERIMENTAL which help includes a |
79 |
> warning; thinking it through, we might even suffix -exp to version. |
80 |
|
81 |
This makes a lot of sense. Since the point of this is to bring simplicity |
82 |
to the process for the user, and more useful bug reports for Gentoo, it |
83 |
seems like a requirement. |
84 |
|
85 |
> > Personally, I wish you luck, it will push the sane users to the |
86 |
> > vanilla-sources tree, which I strongly encourage :) |
87 |
> |
88 |
> I will push them to keep CONFIG_GENTOO_EXPERIMENTAL disabled. :) |
89 |
|
90 |
Yup. |
91 |
|
92 |
-- |
93 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |