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 30A551381F3 for ; Sun, 7 Apr 2013 14:30:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1B926E0D5A; Sun, 7 Apr 2013 14:30:41 +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 19FF6E0D48 for ; Sun, 7 Apr 2013 14:30:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 5A14233DD02 for ; Sun, 7 Apr 2013 14:30:39 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.704 X-Spam-Level: X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5.5 tests=[AWL=0.671, RP_MATCHES_RCVD=-2.373, 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 oiXo4l9jb1tZ for ; Sun, 7 Apr 2013 14:30:28 +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 05E8233DDF7 for ; Sun, 7 Apr 2013 14:30:25 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UOqbt-0002EC-CX for gentoo-dev@gentoo.org; Sun, 07 Apr 2013 16:30:21 +0200 Received: from ppp118-209-51-162.lns20.mel4.internode.on.net ([118.209.51.162]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Apr 2013 16:30:21 +0200 Received: from kensington by ppp118-209-51-162.lns20.mel4.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Apr 2013 16:30:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Michael Palimaka Subject: [gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean Date: Mon, 08 Apr 2013 00:30:08 +1000 Message-ID: References: <20130406200843.6831c4fe@pomiocik.lan> <516117EF.3010007@gentoo.org> 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: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ppp118-209-51-162.lns20.mel4.internode.on.net User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 In-Reply-To: <516117EF.3010007@gentoo.org> X-Archives-Salt: 88645609-c1cf-4a6f-87d6-f0109c555f8c X-Archives-Hash: 8e837aefbce27145b5ece783546a3b66 On 7/04/2013 16:53, Kacper Kowalik wrote: > On 06.04.2013 20:08, Michał Górny wrote: >> Hello, >> >> 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 «don't put awfully big >> files into FILESDIR» or the common sense «use unified diff», but no >> complete and clear policy. >> >> 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: >> >> 1. Patches have to be either in unified or context diff format. Unified >> diff is preferred. >> >> 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'. >> >> 3. Patches have to end with either '.patch' or '.diff' suffix. >> >> 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. >> >> 5. The patch name shall shortly summarize the changes done by it. >> >> 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. >> >> 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). >> >> 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. >> > > Hi, > there's at least one guideline written by the Ancient Ones that I know > [1] It roughly follows the ideas that you've described. I think it'd be > enough if people read it and used as a suggestion not a strict ruling. > Imposing things like lexical order or git-style heading is a bit too > much for me > > Do we really need rules for everything? > > Cheers, > Kacper > > [1] http://dev.gentoo.org/~vapier/clean-patches > We already have policy regarding patches[1], this just expands and formalises it a bit more. Regarding lexical order and git-style headings, my interpretation is that this is a recommendation only. I don't think the intention is to make you rebase complex patches needlessly. vapier's clean-patches document is an informative read, but I don't think devspace is a good method of disseminating of information that may not necessarily reflect the reality of the project. [1]: http://devmanual.gentoo.org/ebuild-writing/misc-files/patches/index.html