Date:	Tue, 1 Jun 2010 08:32:53 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Michal Marek <mmarek@...e.cz>
cc:	linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
	a.beregalov@...il.com, andi@...stfloor.org, dzickus@...hat.com,
	fejes@...o.name, g.liakhovetski@....de, gthelen@...gle.com,
	hschauhan@...ltrace.org, hui.zhu@...driver.com,
	jan3sobi3ski@...il.com, jay@...dhive.com,
	jgunthorpe@...idianresearch.com, jkacur@...hat.com,
	joe@...ches.com, kirr@....spb.ru, lizf@...fujitsu.com,
	nir.tzachar@...il.com, rabin@....in, rientjes@...gle.com,
	roland@...hat.com, saalwaechter@...il.com, shemminger@...tta.com,
	tabbott@...lice.com, u.kleine-koenig@...gutronix.de,
	vbendeb@...gle.com, vda.linux@...glemail.com, wuzhangjin@...il.com,
	xt28@....de
Subject: Re: [GIT] kbuild changes for 2.6.35



On Mon, 31 May 2010, Michal Marek wrote:
> > 
> > I refuse to take stuff like this. If I don't know why somethign happens, I 
> > don't want to pull it.
> 
> Sorry, here is a more complete description of the changes.
> Alternatively, would you pull a branch with the section rename stuff taken
> out?

No, the commits themselves are likely fine, although for the future it 
really would be good to make things like that more descriptive. I just 
want people to try to argue for _why_ I should do a pull, and _what_ I'm 
getting in their "please pull" thing.

It's not always necessary, and some people do it better than others. For 
an example of a really good pull request, look at the ones David Miller 
sends me for networking - they explain what's going on in the pull, so 
it's always easy to pull them because just the request makes me feel like 
David is really on top of things, and lets me have some 30'000 ft overview 
of what's going on.

At the same time, in many cases I obviously pull _without_ any kind of 
real explanation - and that tends to be especially true with maintainers 
that I've worked with for a long time, or areas that are so specialized 
that they are almost self-explanatory (let's be honest: when a filesystem 
maintainer asks me to pull their special filesystem, I'm perfectly happy 
with the overview of "30 changesets to XFS", and there's no need for much 
explanation, although a rough overview of what's been going on is always 
good to see).

So the reason I ask for explanations for kbuild is that not only have we 
had different maintainers, it's an area that affects a lot of different 
things and has historically had issues with odd architectures or old 
binutils tools etc.

So for something like that, I really do want to know what is going on, and 
then when I get a pull request with little to no explanation, and look at 
a trial pull with "gitk ORIG_HEAD.." and see no additional explanation 
there either, I just go "no, I can't pull this, I don't really know what 
it does or why it does so".

> Summary of the changes:
> - A new configuration interface (make nconfig)
> - Improvements to the other *config interfaces
> - Better modpost mismatch reporting
> - Section rename to allow for -ffunction-sections -fdata-sections
> - Untagged builds without LOCALVERSION_AUTO have a '+' appended to the
>   version string
> - Lots of minor fixes & improvements.

So I really want to know _why_ that section rename is specifically like it 
is. Why is ".data..stack" better than ".data.stack"?

			Linus
--
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