[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080212164726.8eecab43.akpm@linux-foundation.org>
Date: Tue, 12 Feb 2008 16:47:26 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: David Miller <davem@...emloft.net>
Cc: greg@...ah.com, torvalds@...ux-foundation.org, jeff@...zik.org,
arjan@...radead.org, sfr@...b.auug.org.au,
linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
linux-arch@...r.kernel.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 16:41:49 -0800 (PST)
David Miller <davem@...emloft.net> wrote:
> Here are some odd-the-cuff
> suggestions:
>
> 1) Make feature-removal-schedule a directory with files in it.
> Everyone touches that file, creating merge issues.
>
> 2) Let's move away from some/dir/{Kconfig,Makefile} schemes and
> instead have each "thing" have it's own Kconfig.foo or
> Makefile.foo that gets automatically sucked into the main
> directory Makefile or Kconfig using file globs or similar.
>
> Even better, encode the building of things into the *.[ch]
> files themselves, and have the Kconfig/Makefile machinery
> automatically extract this information when you build.
3) teach people that you don't always have to add new includes right
at the end of the list
4) teach people that you don't have to add Makefile rules right at the
end of the list
5) ditto feature-removal
6) ditto lots of other things.
My usual way of fixing these things when they pop up is to just move the
offending addition to some random position other than end-of-list. I must
have done this hundreds of times and as yet I don't think anyone has noticed ;)
--
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