lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 8 Oct 2010 22:02:39 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	matt mooney <mfmooney@...il.com>
Cc:	Greg KH <greg@...ah.com>, T Dent <tdent48227@...il.com>,
	linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
	linux-kbuild@...r.kernel.org
Subject: Re: [PATCH 00/33] Staging: Fixed <module-objs> to <module>-y

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@...ah.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@...il.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
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ