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ł Górny 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 «don't put awfully big > >> files into FILESDIR» or the common sense «use unified diff», 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 'upstream' 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 > > > > We already have policy regarding patches[1], this just expands and > 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. > 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. 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 policy 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. -- #friendly-coders -- Where everybody knows your nick ;-)
