On 4/6/13 11:08 AM, Michał Górny wrote: > 1. Patches have to be either in unified or context diff format. Unified > diff is preferred.
Are there any other formats than unified and context diff? If not, it'd be like another "for indoor or outdoor use only" or "home or office use" - i.e. no need to explicitly list all possible options. > 5. The patch name shall shortly summarize the changes done by it. Common sense again. :) And I agree that patches should do that, the question is just whether we put common sense into the policy. > 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. That could be helpful - could this be made more precise though? Is there any existing convention (going beyond git style, but specifically designed for distro or similar patches) we could follow? > 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). Common sense as well. > (2) is likely to be a bikeshed point here. Long story short, epatch has > this fragile patchlevel guessing, users don't have it. If we keep our > patches consistent to a single patchlevel, we gain: > > * ability for users to apply the patches without having them try all > patchlevels by hand. > > * clean error output if patch stops to apply for some reason. > > * no risk that patch will get applied to the wrong file if patch stops > to apply at expected patchlevel and starts to apply on another. The above two points are convincing for me. However, I do acknowledge that it some cases the guessing behavior can be useful for some people (e.g. different layout of git repo vs. release tarballs). How about having a one guessing and one non-guessing variant of epatch, and encouraging the non-guessing one? Paweł
signature.asc
Description: OpenPGP digital signature
