[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1458279643.9556.52.camel@perches.com>
Date: Thu, 17 Mar 2016 22:40:43 -0700
From: Joe Perches <joe@...ches.com>
To: Jeffrey Merkey <jeffmerkey@...il.com>,
Theodore Ts'o <tytso@....edu>,
Stephen Rothwell <sfr@...b.auug.org.au>,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
linux-kbuild <linux-kbuild@...r.kernel.org>
Subject: Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64
On Thu, 2016-03-17 at 23:31 -0600, Jeffrey Merkey wrote:
> On 3/16/16, Jeffrey Merkey <jeffmerkey@...il.com> wrote:
> > On 3/15/16, Theodore Ts'o <tytso@....edu> wrote:
> > > On Tue, Mar 15, 2016 at 01:03:39PM +1100, Stephen Rothwell wrote:
> > > >
> > > > We don't generally PGP (GPG) sign commits in the kernel tree (so "-S"
> > > > is not required), just tags. However we always require that anyone who
> > > > handles a patch adds a Signed-off-by line to the final commit. See
> > > > Documentation/SubmittingPatches Section 11.
> > > In general all commits should have a Signed-Off-By line added. Once
> > > the git branch gets merged, it's hard to tell what is the final commit
> > > and what isn't, and in general different commits will have different
> > > people needing to vouch for the origins for the contents of that commit.
[]
> > I will repost this pull request with a signed-off by line for Linus to
> > consider. I am not certain who all should be included in the review
> > and I have to be careful how many email recipients I copy. I will
> > post to the folks Joe Perches copied.
[]
> Well, Joe updated checkpatch.pl so now there are some more areas of
> cleanup I need to do on the code to remove unsigned casts and replace
> them with unsigned int. I will resubmit at the next merge window for
> 4.7. Have not heard a word from Linus about this, Hey Linus, please
> don't lion-us by throwing us to the lions. :-)
I rather doubt Linus is going to pull this code during
this merge window.
I think you should try to get this into -next immediately
after this current merge window closes in a 10 or so days.
I think you don't have to do random cleanups just to
satisfy checkpatch. Get the code in -next and then
cleanup stuff as you see fit. There will then be
individual commit changelogs for the mostly whitespace
changes that checkpatch might point out.
Powered by blists - more mailing lists