| 1 |
On 7/04/2013 16:53, Kacper Kowalik wrote: |
| 2 |
> On 06.04.2013 20:08, Michał Górny wrote: |
| 3 |
>> Hello, |
| 4 |
>> |
| 5 |
>> As far as I'm aware, we don't really have much of a patch maintenance |
| 6 |
>> policy in Gentoo. There a few loose rules like «don't put awfully big |
| 7 |
>> files into FILESDIR» or the common sense «use unified diff», but no |
| 8 |
>> complete and clear policy. |
| 9 |
>> |
| 10 |
>> Especially considering the late discussion related to the needless |
| 11 |
>> and semi-broken functionality in epatch, I'd like to propose |
| 12 |
>> setting the following rules for patches in tree and in Gentoo-sourced |
| 13 |
>> patchsets: |
| 14 |
>> |
| 15 |
>> 1. Patches have to be either in unified or context diff format. Unified |
| 16 |
>> diff is preferred. |
| 17 |
>> |
| 18 |
>> 2. Patches have to apply to the top directory of the source tree with |
| 19 |
>> 'patch -p1'. If patches are applied to sub-directories, necessary '-p' |
| 20 |
>> argument shall be passed to 'epatch' explicitly. Developers are |
| 21 |
>> encouraged to create patches which are compatible with 'git am'. |
| 22 |
>> |
| 23 |
>> 3. Patches have to end with either '.patch' or '.diff' suffix. |
| 24 |
>> |
| 25 |
>> 4. If possible, patches shall be named in a way allowing them to be |
| 26 |
>> applied in lexical order. However, this one isn't necessary if patches |
| 27 |
>> from an older ebuild are applied to a newer one. |
| 28 |
>> |
| 29 |
>> 5. The patch name shall shortly summarize the changes done by it. |
| 30 |
>> |
| 31 |
>> 6. Patch files shall start with a brief description of what the patch |
| 32 |
>> does. Developers are encouraged to use git-style tags like 'Fixes:' to |
| 33 |
>> point to the relevant bug URIs. |
| 34 |
>> |
| 35 |
>> 7. Patch combining is discouraged. Developers shall prefer multiple |
| 36 |
>> patches following either the upstream commits or a logical commit |
| 37 |
>> sequence (if changes are not committed upstream). |
| 38 |
>> |
| 39 |
>> The above-listed policy will apply to the patches kept in the gx86 tree |
| 40 |
>> (in FILESDIRs) and patch archives created by Gentoo developers. They |
| 41 |
>> will not apply to the patch archives created upstream. |
| 42 |
>> |
| 43 |
> |
| 44 |
> Hi, |
| 45 |
> there's at least one guideline written by the Ancient Ones that I know |
| 46 |
> [1] It roughly follows the ideas that you've described. I think it'd be |
| 47 |
> enough if people read it and used as a suggestion not a strict ruling. |
| 48 |
> Imposing things like lexical order or git-style heading is a bit too |
| 49 |
> much for me |
| 50 |
> |
| 51 |
> Do we really need rules for everything? |
| 52 |
> |
| 53 |
> Cheers, |
| 54 |
> Kacper |
| 55 |
> |
| 56 |
> [1] http://dev.gentoo.org/~vapier/clean-patches |
| 57 |
> |
| 58 |
|
| 59 |
We already have policy regarding patches[1], this just expands and |
| 60 |
formalises it a bit more. |
| 61 |
|
| 62 |
Regarding lexical order and git-style headings, my interpretation is |
| 63 |
that this is a recommendation only. I don't think the intention is to |
| 64 |
make you rebase complex patches needlessly. |
| 65 |
|
| 66 |
vapier's clean-patches document is an informative read, but I don't |
| 67 |
think devspace is a good method of disseminating of information that may |
| 68 |
not necessarily reflect the reality of the project. |
| 69 |
|
| 70 |
[1]: |
| 71 |
http://devmanual.gentoo.org/ebuild-writing/misc-files/patches/index.html |
Archives