[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50CF95D2.3040900@cesarb.net>
Date: Mon, 17 Dec 2012 19:59:46 -0200
From: Cesar Eduardo Barros <cesarb@...arb.net>
To: Borislav Petkov <bp@...en8.de>, Joe Perches <joe@...ches.com>,
Michal Marek <mmarek@...e.cz>, linux-kernel@...r.kernel.org,
linux-kbuild@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
David Howells <dhowells@...hat.com>
Subject: Re: [PATCH] scripts: add checkmaintainers.py
Em 17-12-2012 15:00, Borislav Petkov escreveu:
> On Mon, Dec 17, 2012 at 07:35:44AM -0800, Joe Perches wrote:
>> Perhaps Cesar can use his script as a starting point to find those
>> pattern invalidating commits or maybe add the capability (or a
>> --strict check) to checkpatch.
>
> Or that, I don't have a strict preference.
>
> So, yeah, I can see how checkpatch saying: "you've just renamed a
> file and thusly invalidated a pattern in MAINTAINERS. Pls, consider
> correcting the pattern" could make sense. And I would even add it to
> default functionality since the MAINTAINERS patterns are something we
> want to always have up-to-date, IMO.
Good idea, but a standalone MAINTAINERS checker is still useful, to
check for things checkpatch did not catch, either because it was not
run, or because it did not have enough information.
For instance, consider the case of a patch removing the last file in a
directory going in via one branch, while a patch adding a file pattern
for that same directory goes in via a separate branch. There is no way
checkpatch can catch that.
As for finding the pattern invalidating commits, it is usually not that
hard, a simple "git log -- <pattern>" or similar usually does the trick,
except in the cases where the pattern addition itself was wrong. The
hard part can be interpreting it and the surrounding commits to find out
the committer's intention, how it should affect the MAINTAINERS entry,
and who should get a Cc: of the fix.
--
Cesar Eduardo Barros
cesarb@...arb.net
cesar.barros@...il.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists