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 8885F1381F3 for ; Fri, 12 Apr 2013 13:26:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 93075E0951; Fri, 12 Apr 2013 13:26:04 +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 8E8ABE0938 for ; Fri, 12 Apr 2013 13:26:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 409F733E520 for ; Fri, 12 Apr 2013 13:26:02 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5.5 tests=[AWL=-0.528, FSL_HELO_BARE_IP_2=1.11, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_NUMERIC_HELO=0.865, RP_MATCHES_RCVD=-2.373, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 AeDImmCzgyPC for ; Fri, 12 Apr 2013 13:25:51 +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 AFE0933E458 for ; Fri, 12 Apr 2013 13:25:48 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UQdz7-0008LX-Va for gentoo-dev@gentoo.org; Fri, 12 Apr 2013 15:25:45 +0200 Received: from 91.85.51.2 ([91.85.51.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Apr 2013 15:25:45 +0200 Received: from slong by 91.85.51.2 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Apr 2013 15:25:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: "Steven J. Long" Subject: [gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean Date: Fri, 12 Apr 2013 14:51:32 +0100 Message-ID: <20130412135132.GA10189@sukhisoft.com> 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 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.85.51.2 Content-Disposition: inline In-Reply-To: X-Archives-Salt: 861f7415-8b69-4639-87a5-67d80823d2d8 X-Archives-Hash: bf5c2c1ca2ddc21fd4cfe5da3de3351e On Mon, Apr 08, 2013 at 12:30:08AM +1000, Michael Palimaka wrote: > On 7/04/2013 16:53, Kacper Kowalik wrote: > > On 06.04.2013 20:08, Micha=C5=82 G=C3=B3rny wrote: > >> 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. As soon as I saw this I thought of the same clean-patches doc as Kacper. 1-4 are basically about making patches work better in the automated ebuild framework, and I heartily agree (when it does not entail modifying 'upstrea= m' or rather imported patches; shared with other distros in particular.) Your other post made a lot of sense (with the glob restriction.) > >> 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. > >> Patches in FILESDIR are often those imported from and shared with other distros. > > 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 > > >=20 > We already have policy regarding patches[1], this just expands and=20 > formalises it a bit more. Trouble is it's got a lot less meat than vapier's doc. If you're "expanding and formalising" it's a good opportunity to add more relevant info, as well as the formalities that will make EAPI-6 patching cleaner. =20 > vapier's clean-patches document is an informative read, but I don't=20 > think devspace is a good method of disseminating of information that may= =20 > not necessarily reflect the reality of the project. So why not just merge vapiers work into the devmanual, along with updated info to deal with newer git style tags? ATM the devmanual is woefully thin in comparison; it should be more prescriptive, along with the reasons, just like vapier wrote it the first time around (I actually link people to vapier's doc on IRC, but I'd never link them to the current devmanual as it has little tutorial content for a beginner, just some basic info mostly Gentoo-specific.) Sure, you can make the language a bit nicer, but really before you push pol= icy there needs to be best practice info in place first (and that usually means content with wider development context, like the clean-patches doc.) Regards, steveL.=20 --=20 #friendly-coders -- Where everybody knows your nick ;-)