From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 49E7B1381F3 for ; Mon, 1 Jul 2013 19:51:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 81367E0B05; Mon, 1 Jul 2013 19:50:49 +0000 (UTC) Received: from gerard.telenet-ops.be (gerard.telenet-ops.be [195.130.132.48]) by pigeon.gentoo.org (Postfix) with ESMTP id 5C360E0AF6 for ; Mon, 1 Jul 2013 19:50:48 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by gerard.telenet-ops.be with bizsmtp id v7qn1l00T2khLEN0H7qnNR; Mon, 01 Jul 2013 21:50:47 +0200 Date: Mon, 1 Jul 2013 21:50:45 +0200 From: Tom Wijsman To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration. Message-ID: <20130701215045.5f8099d3@TOMWIJ-GENTOO> In-Reply-To: <20130701193330.GA31073@kroah.com> References: <20130701164149.131490f8@TOMWIJ-GENTOO> <20130701181749.GA3831@kroah.com> <20130701205615.18fdcea2@TOMWIJ-GENTOO> <20130701212542.60f86307@TOMWIJ-GENTOO> <20130701193330.GA31073@kroah.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.19; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ggR3gdM=+Y7WjiMV7=9IEQY"; protocol="application/pgp-signature" X-Archives-Salt: 048fd525-4a9e-4211-9690-d558231b6be6 X-Archives-Hash: 31f3e030554c90bef1bd7eccaf677f86 --Sig_/ggR3gdM=+Y7WjiMV7=9IEQY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 1 Jul 2013 12:33:30 -0700 Greg KH wrote: > On Mon, Jul 01, 2013 at 09:25:42PM +0200, Tom Wijsman wrote: > > On Mon, 1 Jul 2013 14:09:57 -0500 > > Matthew Summers wrote: > > > If the patchset patches the kernel's core, it doesn't matter what > > > CONFIG_* option is set the core kernel code > > > _has_now_been_changed_. This is the crux of the argument, I > > > believe. AUFS simply being one example of this. I'm sure there > > > are others. > >=20 > > As per my response to that point, this statement is no longer true. > >=20 > > Let me re-iterate it here: > >=20 > > Earlier I mentioned "3) The patch should not affect the build by > > default."; if it does, we have to adjust it to not do that, this is > > something that can be easily scripted. It's just a matter of > > embedding each + block in the diff with a config check and updating > > the counts. >=20 > Wonderful, now you are maintaining a patch that looks nothing like the > one created by the original developers, nor tested by anyone else > other than gentoo developers. I can convert the original developer's patch whenever he updates it; or on top of that, write a script to generate the original patch back. > Playing fast-and-loose with kernel patches is a fun thing to do, but > really, why? Users love doing this type of thing, but the > interactions of different kernel patches with core subsystems is > almost always a non-trivial thing. Our main intent is to provide them and deduplicate work; if users have a problem with one of the patches and it isn't clear to us, we can forward them to the authors. Nothing in this proposal inherits that we must support the patches; especially not, since they are "experimental". > I'm not saying not to do this, but consider this a friendly warning > that this is going to be a MAJOR pain to maintain and debug over the > long-run. Maybe, maybe not; plan is to do a slow start, congestion avoidance. :) > But hey, what do I know? It's not like I've ever done this before and > had the experience of the resulting fall-out that took years to > recover from on user's production systems, causing a number of > enterprise Linux companies to swear that they would never do this > type of thing again... I covered this in the conditions as well as the F.A.Q.; feel free to read about it again, this does not affect them unless they explicitly want them to enable CONFIG_GENTOO_EXPERIMENTAL which help includes a warning; thinking it through, we might even suffix -exp to version. > Personally, I wish you luck, it will push the sane users to the > vanilla-sources tree, which I strongly encourage :) I will push them to keep CONFIG_GENTOO_EXPERIMENTAL disabled. :) > greg "kids, get off my lawn!" k-h Gentoo (Penguin) and Larry do not necessarily like grass; they might like ice, fire, water, earth, ... whatever their appetite craves. --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/ggR3gdM=+Y7WjiMV7=9IEQY Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJR0d2VAAoJEJWyH81tNOV9bIcH/1hJZvRtgm4mjpFdS5JCRN3X aKlzE5fjcIg/d+clnjWYob/4LJrGFzV6siYipkinWyGp58mgi4jrK7AJSghbIQHn khnbGQuozhUG8RijMKtTG8jINCLcQy5idedGqnKI2Iex8JRedxTiZi21w+WVwB5H tY3bvMpBfTqymINE1Bg9aGoHrrqwNy4OFWZnbRXvo7UM30021y/ia9OMiQ+WLIQj ehHGIasapjho3z2P6QR19508it+agQC1M+OLGwdPVanHlnSngLxgWCsQHeZKF1oB h6XQ5PwIaI8Tdmt3RRXfmsaOPDp2W8HTlQXLsnViZbMvv45AitYtrinyLku+jkI= =47mZ -----END PGP SIGNATURE----- --Sig_/ggR3gdM=+Y7WjiMV7=9IEQY--