Gentoo Archives: gentoo-dev

From: "Paweł Hajdan
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
Date: Sat, 06 Apr 2013 19:02:37
In Reply to: [gentoo-dev] [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean by "Michał Górny"
1 On 4/6/13 11:08 AM, Michał Górny wrote:
2 > 1. Patches have to be either in unified or context diff format. Unified
3 > diff is preferred.
5 Are there any other formats than unified and context diff? If not, it'd
6 be like another "for indoor or outdoor use only" or "home or office use"
7 - i.e. no need to explicitly list all possible options.
9 > 5. The patch name shall shortly summarize the changes done by it.
11 Common sense again. :) And I agree that patches should do that, the
12 question is just whether we put common sense into the policy.
14 > 6. Patch files shall start with a brief description of what the patch
15 > does. Developers are encouraged to use git-style tags like 'Fixes:' to
16 > point to the relevant bug URIs.
18 That could be helpful - could this be made more precise though? Is there
19 any existing convention (going beyond git style, but specifically
20 designed for distro or similar patches) we could follow?
22 > 7. Patch combining is discouraged. Developers shall prefer multiple
23 > patches following either the upstream commits or a logical commit
24 > sequence (if changes are not committed upstream).
26 Common sense as well.
28 > (2) is likely to be a bikeshed point here. Long story short, epatch has
29 > this fragile patchlevel guessing, users don't have it. If we keep our
30 > patches consistent to a single patchlevel, we gain:
31 >
32 > * ability for users to apply the patches without having them try all
33 > patchlevels by hand.
34 >
35 > * clean error output if patch stops to apply for some reason.
36 >
37 > * no risk that patch will get applied to the wrong file if patch stops
38 > to apply at expected patchlevel and starts to apply on another.
40 The above two points are convincing for me. However, I do acknowledge
41 that it some cases the guessing behavior can be useful for some people
42 (e.g. different layout of git repo vs. release tarballs).
44 How about having a one guessing and one non-guessing variant of epatch,
45 and encouraging the non-guessing one?
47 Paweł


File name MIME type
signature.asc application/pgp-signature