| 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. |
| 4 |
|
| 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. |
| 8 |
|
| 9 |
> 5. The patch name shall shortly summarize the changes done by it. |
| 10 |
|
| 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. |
| 13 |
|
| 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. |
| 17 |
|
| 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? |
| 21 |
|
| 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). |
| 25 |
|
| 26 |
Common sense as well. |
| 27 |
|
| 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. |
| 39 |
|
| 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). |
| 43 |
|
| 44 |
How about having a one guessing and one non-guessing variant of epatch, |
| 45 |
and encouraging the non-guessing one? |
| 46 |
|
| 47 |
Paweł |
Archives