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 C4BB41381F3 for ; Tue, 30 Apr 2013 04:34:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AB673E08D4; Tue, 30 Apr 2013 04:34:15 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AB979E0871 for ; Tue, 30 Apr 2013 04:34:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id E5D3F33DD61 for ; Tue, 30 Apr 2013 04:34:13 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5.5 tests=[AWL=0.059, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.442, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOsVxKVjo_CR for ; Tue, 30 Apr 2013 04:34:04 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 6697C33DED8 for ; Tue, 30 Apr 2013 04:34:02 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UX2GM-0000vL-1F for gentoo-dev@gentoo.org; Tue, 30 Apr 2013 06:33:58 +0200 Received: from 71-17-69-121.yktn.hsdb.sasknet.sk.ca ([71.17.69.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Apr 2013 06:33:58 +0200 Received: from dirtyepic by 71-17-69-121.yktn.hsdb.sasknet.sk.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Apr 2013 06:33:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Ryan Hill Subject: [gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean Date: Mon, 29 Apr 2013 22:44:14 -0600 Organization: Gentoo Message-ID: <20130429224414.6b5e94a8@caribou.gateway.2wire.net> References: <20130406200843.6831c4fe@pomiocik.lan> 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-SHA512; boundary="Sig_/Jv3qynOJ71DIKfFO5Avyl_x"; protocol="application/pgp-signature" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 71-17-69-121.yktn.hsdb.sasknet.sk.ca X-Newsreader: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) X-Archives-Salt: 0ab6b1c6-e2e2-4a38-ad9f-8d44843f68f3 X-Archives-Hash: 02201d795efed09056f1fd11b4c74452 --Sig_/Jv3qynOJ71DIKfFO5Avyl_x Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 6 Apr 2013 20:08:43 +0200 Micha=C5=82 G=C3=B3rny wrote: > Hello, >=20 > As far as I'm aware, we don't really have much of a patch maintenance > policy in Gentoo. There a few loose rules like =C2=ABdon't put awfully big > files into FILESDIR=C2=BB or the common sense =C2=ABuse unified diff=C2= =BB, but no > complete and clear policy. >=20 > Especially considering the late discussion related to the needless > and semi-broken functionality in epatch, I'd like to propose > setting the following rules for patches in tree and in Gentoo-sourced > patchsets: >=20 > 1. Patches have to be either in unified or context diff format. Unified > diff is preferred. Yes. > 2. Patches have to apply to the top directory of the source tree with > 'patch -p1'. If patches are applied to sub-directories, necessary '-p' > argument shall be passed to 'epatch' explicitly. Developers are > encouraged to create patches which are compatible with 'git am'. Bikeshedding below. > 3. Patches have to end with either '.patch' or '.diff' suffix. Yes. > 4. If possible, patches shall be named in a way allowing them to be > applied in lexical order. However, this one isn't necessary if patches > from an older ebuild are applied to a newer one. Even more below. > 5. The patch name shall shortly summarize the changes done by it. Yes. > 6. Patch files shall start with a brief description of what the patch > does. Developers are encouraged to use git-style tags like 'Fixes:' to > point to the relevant bug URIs. Yes. > 7. Patch combining is discouraged. Developers shall prefer multiple > patches following either the upstream commits or a logical commit > sequence (if changes are not committed upstream). Kinda. >=20 > The above-listed policy will apply to the patches kept in the gx86 tree > (in FILESDIRs) and patch archives created by Gentoo developers. They > will not apply to the patch archives created upstream. >=20 >=20 > RATIONALE > --------- >=20 > The main reason for the whole policy is to let Gentoo supply users with > consistent and friendly patches. That is, patches which can be used > directly on a source tree or submitted upstream without any additional > actions from user. >=20 > (1) lists the most common patch formats. The formats shall be generally > both readable and reusable whenever possible. I wanted just 'unified > diff' but ulm suggested that we should also support those upstreams who > use 'context diffs'. >=20 >=20 > (2) is likely to be a bikeshed point here. Long story short, epatch has > this fragile patchlevel guessing, users don't have it. If we keep our > patches consistent to a single patchlevel, we gain: >=20 > * ability for users to apply the patches without having them try all > patchlevels by hand. >=20 > * clean error output if patch stops to apply for some reason. >=20 > * no risk that patch will get applied to the wrong file if patch stops > to apply at expected patchlevel and starts to apply on another. If I can't drop patches from an upstream mailing list with a different repo structure than source, or just a random user who doesn't know better, into = my patchdir I'm going to be very grumpy. Our patches should be -p1, I agree. I respin any patches I find that aren'= t. The first two points are nice, but not worth it to me in particular. The t= hird I don't see the risk. What are the chances of that patch actually applying successfully? It'll fail, and you root it out. And since all our own patc= hes will be -p1 this becomes a tiny corner case. > Also, by creating git-format patches, we gain the ability of rebasing > and updating the patches easily. Even with non-git upstreams, we can > do: >=20 > git init; git add -A; git commit -m 1; git am ... > > (3) should be mostly obvious. The main idea is that if we apply a whole > patchdir, we should be able to easily tell between patches > and auxiliary files like 'README' or Debian's 'series'. >=20 > I have never seen a patch file named other than '*.patch' or '*.diff'. > Therefore, I think that it's better to just require those rather than > trying to provide a sane list of excludes. >=20 >=20 > (4) is mostly about friendliness (again). Since shell does filename > expansion in lexical order, it's just great for user to be able apply > patches like: >=20 > git am /usr/portage/foo/bar/files/198-*.patch >=20 > The other sentence is not to enforce this rule e.g. when the same patch > is applied to different versions of the same package. Although with > a fair of trickery that could be gotten working, I don't think it will > be user-friendly anymore :). That's useful but ${PN}-${PV}-desc.patch is the currently accepted conventi= on. What you're suggesting here is a suggested workflow. I don't think it belo= ngs in a policy doc, at least as it's own section, or at least until it becomes more commonplace. > (5) makes finding a particular patch of interest easier, while (6) > makes sure that the purpose of the patch can be read from patch alone. > In both cases, having described patches is much better than having to > look into ebuilds for explanations. >=20 >=20 > (7) is because merged patches are usually hard to read and completely > not suitable for submitting anywhere. Well, patches should do one thing, agreed. But I'm not adding 4 patches to respect LDFLAGS, use CFLAGS while linking, install into /usr, and fix the version number in a 30 line Makefile. I'm adding foo-0.01-makefile.patch w= hich does one thing (fixes crappy-ass Makefile). I can live with "discouraged" = though. --=20 gcc-porting toolchain, wxwidgets @ gentoo.org --Sig_/Jv3qynOJ71DIKfFO5Avyl_x Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCgAGBQJRf0wjAAoJEO04vUmVeoRjsl8H/Rx12jsC2uI2My/irvv3bCAE 0h33ZrlzSxVgmu0z/+ByIViqj0qa1D4d4AVb0C2U+sTGeWVLJgLy3HoZpvo2+i9x Vm0tKNNJZkLnN0wDfS0HcxguhmTr7TqIH/tfB1V7qSWcpsQ9rN/9m9kccSE52jyM AWyZqtRQTOzTclkHoju0x5XxMA4Yxxxkuh7Hb+Ao7j1+Ph9mdhTmq+gTKX6qn3RO ySkl8VuL/SzNtsWk0nLMcZcMuwF2fFfJtcJs/oQ1cjst8F2fWcz1e05Hsn4VQvj9 +jUoDSEQb8leMXkFh3CQfXlP8taQyAhvxWiC4oLtQR6Vb0mJIzGienlNprIkkg0= =ryXP -----END PGP SIGNATURE----- --Sig_/Jv3qynOJ71DIKfFO5Avyl_x--