Hi all,
Commit
9bfe33ba29d0 ("x86/CPU: Add Icelake model number")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
On Sun, Feb 24, 2019 at 01:19:25AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> 9bfe33ba29d0 ("x86/CPU: Add Icelake model number")
>
> is missing a Signed-off-by from its committer.
Thanks for the catch. Andy, please check your commit scripts as should
definitely be automated in our workflow.
I have corrected it.
--
Darren Hart
VMware Open Source Technology Center
On Sun, Feb 24, 2019 at 01:19:25AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> 9bfe33ba29d0 ("x86/CPU: Add Icelake model number")
>
> is missing a Signed-off-by from its committer.
>
Hi Stephen,
Apologies if I've asked you this before... I didn't find it after some
searching.
We should be catching errors like this before they hit next. First,
there is no reason we can't catch them - unlike the integration failures
only next can catch. Second, once they are in next, there is no "right"
way to fix them. Either rebase or send the bad patch to mainline - both
are bad. Don't get me wrong, I'm glad next catches them.... but I'd like
to get to the point where it doesn't trigger on our subsystem :-)
Are your patch mechanics tests available for us to integrate into our
commit and prepublication checks?
Thanks,
--
Darren Hart
VMware Open Source Technology Center
Hi Darren,
On Sat, 23 Feb 2019 09:52:07 -0800 Darren Hart <[email protected]> wrote:
>
> Apologies if I've asked you this before... I didn't find it after some
> searching.
>
> We should be catching errors like this before they hit next. First,
> there is no reason we can't catch them - unlike the integration failures
> only next can catch. Second, once they are in next, there is no "right"
> way to fix them. Either rebase or send the bad patch to mainline - both
> are bad. Don't get me wrong, I'm glad next catches them.... but I'd like
> to get to the point where it doesn't trigger on our subsystem :-)
>
> Are your patch mechanics tests available for us to integrate into our
> commit and prepublication checks?
I have attached the current version of my check scripts (I can't use
git hooks since I want to do these checks when I fetch trees). They
both take a range of commits (I usually pass "^origin/master <old SHA
for branch>...<new SHA for branch>" (only 2 dots if the branch is just
fast forwarded).
These could obviously be simplified because they also generate most of
the appropriate mail messages ...
--
Cheers,
Stephen Rothwell