Gentoo Archives: gentoo-dev

From: Tom Wijsman <TomWij@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
Date: Fri, 05 Jul 2013 09:07:54
Message-Id: 20130705110433.704199b6@TOMWIJ-GENTOO
In Reply to: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration. by "Steven J. Long"
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
[gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration. "Steven J. Long" <slong@××××××××××××××××××.uk>