From: Sam Ravnborg <sam@ravnborg.org>
To: matt mooney <mfmooney@gmail.com>
Cc: Greg KH <greg@kroah.com>, T Dent <tdent48227@gmail.com>,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-kbuild@vger.kernel.org
Subject: Re: [PATCH 00/33] Staging: Fixed <module-objs> to <module>-y
Date: Fri, 8 Oct 2010 22:02:39 +0200 [thread overview]
Message-ID: <20101008200239.GA28912@merkur.ravnborg.org> (raw)
In-Reply-To: <AANLkTi=9N4e7fBekOaUa7OmPcaqicAgkC2aDT0HbJE8p@mail.gmail.com>
On Fri, Oct 08, 2010 at 11:09:11AM -0700, matt mooney wrote:
> On Fri, Oct 8, 2010 at 6:46 AM, Greg KH <greg@kroah.com> wrote:
> > On Fri, Oct 08, 2010 at 12:16:35AM -0700, matt mooney wrote:
> >> On Thu, Oct 7, 2010 at 6:35 PM, T Dent <tdent48227@gmail.com> wrote:
> >> > I patch against the next-20101006 tree.
> >> >
> >> > The patch series replace use of <module>-objs with <module>-y in the
> >> > staging directory.
> >>
> >> Commit messages are written in the present tense. You happen to be
> >> using two different tenses within the commit message, which is truly
> >> odd. And why did you not split apart those atrocious statements with
> >> the infinite column width?
> >
> > As Dan said, we understand what is happening here, and we do not have
> > grammer police for changelog comments, thank goodness.
> >
> >> This patch series adds little benefit. As Sam has suggested, a more
> >> general cleanup would be a better goal, and staging is an area that
> >> needs extra attention some of which has already been pointed out in
> >> other emails.
> >
> > But these patches are all good to have, so I will be applying them,
> > please don't think they are unwanted at all.
> >
>
> This is good to know. I wonder how well received these changes will be
> in other parts of the kernel though. I purposefully started in a
> subsystem you maintain since I figured any criticism from you would be
> constructive and you wouldn't just knack without reason.
In staging it is OK with small very janitorial patches - at
least I see lots of these applied there.
But in the world outside staging most maintainers would expect
you to do a full update if you decide to clean up their Makefile.
If the updates are bigger then split it up.
But for trivial updates batch the Makefiles.
If you final patches end up:
1) Making the files more readable, and more standard looking
2) and do not add a lot of lines
then you will likely see that most maintainers will accept it.
But you also have to convince tham that you did a proper job
testing your changes.
A good test on Makefile cleanup is that nothing should rebuild
due to the patch being applied. This simple test have saved me
from a few brown papaer bag bugs in the past.
Sam
prev parent reply other threads:[~2010-10-08 20:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-08 1:35 [PATCH 00/33] Staging: Fixed <module-objs> to <module>-y T Dent
2010-10-08 7:16 ` matt mooney
2010-10-08 8:39 ` T Dent
2010-10-08 8:55 ` Dan Carpenter
2010-10-08 18:05 ` matt mooney
2010-10-08 13:46 ` Greg KH
2010-10-08 18:09 ` matt mooney
2010-10-08 18:33 ` Greg KH
2010-10-08 20:02 ` Sam Ravnborg [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101008200239.GA28912@merkur.ravnborg.org \
--to=sam@ravnborg.org \
--cc=greg@kroah.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mfmooney@gmail.com \
--cc=tdent48227@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox