[gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
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 ;-)
[gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On 7/04/2013 04:22, Markos Chandras wrote: On 6 April 2013 19:08, Michał Górny mgo...@gentoo.org wrote: Hello, ... What are your thoughts? Maybe it is time to setup a patch tracking system like Debian[1]? Sometimes it is really hard to understand what patches are applied by an ebuild (especially when all the build process is handled by an eclass) and/or when people keep a separate .tar.* with all the patches. Debian makes is so much easier to see what patches each package contains. [1]http://patch-tracker.debian.org/ -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang I have always found Debian's patch tracker very useful, I would definitely support us implementing something similar.
[gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
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
[gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On 7/04/2013 07:01, Robin H. Johnson wrote: On Sat, Apr 06, 2013 at 08:08:43PM +0200, Michał Górny wrote: 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. What about patches created by upstream, but stored in the FILESDIR (eg from upstream mailing lists, bugfixes before the next release). We want to keep them intact and not respin them. What sort of respinning are you concerned about? It seems that each point could be addressed trivially with a text editor.
Re: [gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On Mon, Apr 08, 2013 at 12:36:36AM +1000, Michael Palimaka wrote: On 7/04/2013 07:01, Robin H. Johnson wrote: On Sat, Apr 06, 2013 at 08:08:43PM +0200, Michał Górny wrote: 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. What about patches created by upstream, but stored in the FILESDIR (eg from upstream mailing lists, bugfixes before the next release). We want to keep them intact and not respin them. What sort of respinning are you concerned about? It seems that each point could be addressed trivially with a text editor. The -p1 directive primarily. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
