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 8E4401381F3 for ; Sat, 6 Apr 2013 19:40:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B023CE08CA; Sat, 6 Apr 2013 19:40:28 +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 8F878E08BE for ; Sat, 6 Apr 2013 19:40:27 +0000 (UTC) Received: from pomiocik.lan (77-253-156-83.adsl.inetia.pl [77.253.156.83]) (using SSLv3 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id D08A133DD1E; Sat, 6 Apr 2013 19:40:24 +0000 (UTC) Date: Sat, 6 Apr 2013 21:41:27 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-dev@lists.gentoo.org Cc: phajdan.jr@gentoo.org Subject: Re: [gentoo-dev] [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean Message-ID: <20130406214127.52b4b500@pomiocik.lan> In-Reply-To: <51607144.5040003@gentoo.org> References: <20130406200843.6831c4fe@pomiocik.lan> <51607144.5040003@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; 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-SHA512; boundary="Sig_/3ejQio8wtTgLhN8YiJVWp5L"; protocol="application/pgp-signature" X-Archives-Salt: 4bdef04c-9d25-471e-a3f7-6931a9998abe X-Archives-Hash: cb4e10439944381630159fadf244e30d --Sig_/3ejQio8wtTgLhN8YiJVWp5L Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 06 Apr 2013 12:02:28 -0700 ""Pawe=C5=82 Hajdan, Jr."" wrote: > On 4/6/13 11:08 AM, Micha=C5=82 G=C3=B3rny wrote: > > 5. The patch name shall shortly summarize the changes done by it. >=20 > Common sense again. :) And I agree that patches should do that, the > question is just whether we put common sense into the policy. Well, I think it's more like pointing out the few people who rather use very short and ambiguous names. Although the git naming is bit verbose here, I prefer that than 'lm.patch'. find /usr/portage -name '*.patch' \ | awk -F/ '{ print length($NF) " " $NF }' | sort -k1 -n > /tmp/lol > > 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. >=20 > That could be helpful - could this be made more precise though? Is there > any existing convention (going beyond git style, but specifically > designed for distro or similar patches) we could follow? I would honestly just go for the git style. It's the first thing that really succeeded in standardizing patches. Inventing something new is not really necessary, I believe. > > 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). >=20 > Common sense as well. Tell that to the people who believe in space savings :). > > (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. >=20 > The above two points are convincing for me. However, I do acknowledge > that it some cases the guessing behavior can be useful for some people > (e.g. different layout of git repo vs. release tarballs). >=20 > How about having a one guessing and one non-guessing variant of epatch, > and encouraging the non-guessing one? In the end we will probably have a simple patch applying method from PMS, and we will keep the epatch eclass monster -- at least for some time. To be honest, I'd rather prefer to find a good way to help people add correct '-p'. We can -- for example -- make portage try various patchlevels and suggest one if applying patch failed. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/3ejQio8wtTgLhN8YiJVWp5L Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQJ8BAEBCgBmBQJRYHpnXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEK2W4QAKUMbQ8XpXkUXb+RCrNR0OGI Sftu8gyulKxDl+Lijhd+FI8bGnin1TGoHQdKO6wi997/RUwt3SlwMJI38Ahzz+TG 6vMG1uSeJajtTzyX6wWl7l7VwfI7MOk6XZPZkqa3Loh08pIaxfhWD7Kg7kOKaa/l al73zuWDuja22OfIQTgjy7aWHNLaaChPfX5AoBb2d7kGrAkKVMGjVBJ0S/dTFQDX 5aU5eyDeBIsuPRoAVXE1LO7Rfgfdu9DOuY4JFm5QdMAjiKAebjnk/1t5yrul1Hwt uoR/Y+QLBnjndn2fFzd96oztgwn4zknokOppxUizCE1UizSB4P4azWBCJqeTLQjS gQUmATcayhviNHiCG8S1DWcyQ4Ih4Z7RfOlfGdoas2b1j0VvrLqcSF05rfn/O8Ot gst92E8x7FE6uq8WSTX2iy2C5kU943wTQ+yD2XgZySOxE9WYE5vvfShh/25NxCcC XubaEM8WQrbjRh8YTZMSEt7Ly7J2mgvQ43jkeTtEiG/wxpyWBQEJUzSAL+/0gvHf qUYDjD5PTtJPPvkfPG+8GtfNDSMcg7QvCM9bTdUzJ3/EJQbXqAmSSihLTl1wh+hE rdAie2ws6czG5oxIyx06KDbucCuodTcvCPHaEsvV93F6eCr5mZmE7mod2V9ENu5u A79flppTGrm7SwRG8ocM =cZJO -----END PGP SIGNATURE----- --Sig_/3ejQio8wtTgLhN8YiJVWp5L--