1 |
On Fri, 5 Jul 2013 09:38:10 +0100 |
2 |
"Steven J. Long" <slong@××××××××××××××××××.uk> wrote: |
3 |
|
4 |
> Tom Wijsman wrote: |
5 |
> > |
6 |
> > Yes, we currently have "base" and "extras" tarballs for genpatches; |
7 |
> > it is trivial to add a "experimental" tarball to this set, all the |
8 |
> > optional experimental patches will be in that tarball. This is also |
9 |
> > handy for maintainers of other distros whom use genpatches. |
10 |
> |
11 |
> That's cool. The bit about the user explicitly opting-in to 'fragile' |
12 |
> patches still is of concern, however. |
13 |
|
14 |
Why is this still of concern? (See the next response before replying) |
15 |
|
16 |
> > There shouldn't be a problem here unless the user applies a lot of |
17 |
> > patches that could introduce a colliding patch; in this case the |
18 |
> > user either has to fix the conflicting patch or exclude ours. We |
19 |
> > can't know for ourselves which patches will be troublesome in this |
20 |
> > light; but well, I feel like this only happens on a very |
21 |
> > exceptional basis. If an user keeps this amount of patches, ours |
22 |
> > are probably not needed. |
23 |
> |
24 |
> No, the problem is as mentioned, with patches for which disabling the |
25 |
> configure option, does not stop the patch from changing anything. Such |
26 |
> as aufs, as has been outlined by Greg K-H earlier in the thread. |
27 |
|
28 |
My original post mentions "3) The patch should not affect the build by |
29 |
default.", which I later clarified with "It's just a matter of embedding |
30 |
each + block in the diff with a config check and updating the counts."; |
31 |
in detail we QA check whether all blocks contain such a config check. |
32 |
|
33 |
It does not change anything other than insert some code which won't be |
34 |
parsed if you don't enable the relevant option in the menu config. |
35 |
|
36 |
> [... SNIP ...]; and can hardly be called "Proper integration", imo. |
37 |
|
38 |
Why not? |
39 |
|
40 |
> After all, these are experimental patches. If they don't play nicely, |
41 |
> don't let them out of the sandbox, unless the user tells us to. |
42 |
|
43 |
It's the user that can let each individual patch out of its sandbox. |
44 |
|
45 |
> Having a clear "policy" on that makes negotiating with patch authors |
46 |
> much simpler too, and it's far more likely they'll fall into line |
47 |
> where possible, just as upstreams are usually quite happy to apply |
48 |
> portability patches: it means they get more users and feedback. |
49 |
|
50 |
Not sure what is meant by this; but given my above clarifications, I |
51 |
think you were missing a detail in the approach that is taken. |
52 |
|
53 |
-- |
54 |
With kind regards, |
55 |
|
56 |
Tom Wijsman (TomWij) |
57 |
Gentoo Developer |
58 |
|
59 |
E-mail address : TomWij@g.o |
60 |
GPG Public Key : 6D34E57D |
61 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |