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-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
