Re: [gentoo-dev] [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean

[Michał Górny]

On Sat, 06 Apr 2013 12:02:28 -0700
""Paweł Hajdan, Jr."" <phajdan.jr@g.o> wrote:

> On 4/6/13 11:08 AM, Michał Górny wrote:
> > 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.

Well, I think it's more like pointing out the few people who rather use
very short and ambiguous names. Although the git naming is bit verbose
here, I prefer that than 'lm.patch'.

find /usr/portage -name '*.patch' \
  | awk -F/ '{ print length($NF) " " $NF }' | sort -k1 -n > /tmp/lol

> > 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?

I would honestly just go for the git style. It's the first thing that
really succeeded in standardizing patches. Inventing something new is
not really necessary, I believe.

> > 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.

Tell that to the people who believe in space savings :).

> > (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?

In the end we will probably have a simple patch applying method
from PMS, and we will keep the epatch eclass monster -- at least
for some time.

To be honest, I'd rather prefer to find a good way to help people add
correct '-p'. We can -- for example -- make portage try various
patchlevels and suggest one if applying patch failed.

-- 
Best regards,
Michał Górny