Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] API replacement/deprecation

[Geert Uytterhoeven <geert@linux-m68k.org>]

On Fri, Sep 7, 2018 at 1:19 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Thu, 6 Sep 2018 11:24:11 -0700 Kees Cook <keescook@chromium.org> wrote:
> > If there was an agreement by all maintainers that deprecated
> > functions/patterns should not be added, and we documented the
> > deprecation somewhere like Documentation/process/deprecated.rst, then
> > we could make the declaration that if such functions got added (it's
> > easy to mechanically check for them), it would be the responsibility
> > of the author and maintainer chain to see that it got fixed before the
> > release is cut. We already have this for things like "breaks the x86
> > allmodconfig build" or similar. The checking would be manual, and the
> > enforcement would be by agreement, but it'd be better than the kind of
> > "please don't do this" hand-waving we've had in the past.
>
> I could do this in linux-next, of course, the same way I check for
> missing signed-off-bys.  All I would need is the list of deprecated
> things.

The sooner it is detected, the better.
So that means, in order of decreasing agility:
  1. git commit hook:
       - Needs installation of the hook everywere,
       - Anyone still not using git?
  2. checkpatch:
     - All patch authors should run checkpatch,
     - All maintainers should, too.
  3. coccinelle script et al run by bots:
     - Needs rework when detected (list bot), or fixup (already in next).

Any other options?

So checkpatch looks like the best option to me.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds