No cute April 1st shenanigans, just a regular -rc release that happened to 
come up today because I was waiting for the input layer oops-fixes to be 
ready and tested.

I think the dirstat continues to be fairly informative, with arch/ and 
drivers dominating as usual. And within arch, a fair amount of the line 
noise are all those defconfigs. I wish we had some saner way of handling 
that, but apart from causing noise in the statistics there aren't any real 
downsides. Anyway, here is:

	  15.2% arch/mips/configs/
	  17.5% arch/mips/
	   2.3% arch/powerpc/configs/
	   3.1% arch/powerpc/
	   7.8% arch/sparc64/kernel/
	   8.1% arch/sparc64/
	   4.3% arch/x86/kernel/
	   2.0% arch/x86/lguest/
	   3.2% arch/x86/mach-rdc321x/
	  11.0% arch/x86/
	  40.6% arch/
	   2.2% drivers/char/
	   2.6% drivers/lguest/
	   2.3% drivers/net/igb/
	   8.7% drivers/net/netxen/
	   2.1% drivers/net/phy/
	  15.8% drivers/net/
	  30.6% drivers/
	   4.7% fs/
	   5.0% include/asm-sh/
	   8.6% include/
	   3.9% net/
	   7.5% scripts/

but the bulk of the fixes are the usual random one-liners. Some of the 
"bulk" above (like the arch/x86/kernel changes) are actually just moving 
some functions around in a file, so they look like larger diffs than they 
actually are.

A lot of the one-liners are some sparse cleanups, which is probably 
unnecessary noise at this point, but when Al sends me a series I just tend 
to apply it because his patches tend to be rather careful and basically 
always correct.

The big thing that is actually *noticeable* to most people is that this 
should fix the two top regressions: we've had some suspend-resume 
regressions due to the stupid ACPI _PTS orderign issues, and while the 
cleanups were left, the ordering changes were reverted. So that should fix 
issues for some people (of course, the people who had it fixed are 
unhappy, but regressions are worse).

The other thing that bit a number of people and is now fixed (and that 
also probably often showed up ...
[ message continues ]

We (the arch maintainers) could try to do the bulk of the defconfig
updates at about -rc2 or -rc3 time, if you'd prefer.

Paul.
--

[ message continues ]

Well, that part isn't the one that I think is bothersome - I just wonder 
if the whole "defconfig" mess is worth keeping with the kernel at _all_.

It also causes tons of noise whenever I happen to do something like "git 
grep CONFIG_XYZZY" to see where some config variable is used etc.

So I was more wondering whether maybe there could be better ways of doing 
that whole thing. 

		Linus
--

[ message continues ]

I have a trivial script that does "build all defconfigs", and it has 
resulted in me reporting and fixing dozens of bugs in 2.6.25
(and some regressions in gcc 4.3).

And I use it for verifying that patches don't break the compilation.

Different to randconfig builds the defconfigs allow me to cover most 

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--

[ message continues ]

Having the defconfigs seems to be useful for the embedded folks,
judging by the number of defconfigs they have.  They generally have a
defconfig for each reference board.

Those defconfigs would be much smaller and change much less often if
they could be expressed as a delta from some other defconfig.  So we'd
end up with a small number of base defconfigs plus a set of board
defconfigs that would say effectively "use the options from that other
defconfig, plus turn this on and that off".

On the whole, I think defconfigs are useful because we have so many
configuration options, and the defaults and help texts for many of the
options are not always helpful.

We could possibly do without defconfigs if we put effort into making
sure that all the "depends" and "default" values in all the Kconfig
files are sensible.  Ideally, a user could select something like
"32-bit powermac support" and take the defaults for everything else,
and get something sensible for a 32-bit powermac.  We're not at that
point, and I think it would take considerable effort to get there.

I would like to see something better than what we have at the moment
(whether one of the two ideas above, or something else) because I find
maintaining the defconfigs a bit of a pain myself.

Paul.
--

[ message continues ]

I'm thinking of getting rid of the board specific defconfigs for PowerPC
4xx actually.  We already have ppc44x_defconfig that builds most boards,
and ppc40x_defconfig will be coming soon.


IIRC, Fedora builds their kernels using such a mechanism, though it's
done in the RPM specfile with a perl script.  Maybe that's something to
look at to start with.

josh

--

[ message continues ]

kconfig allready allow you to override values simply by appending to
the end of the .config file.
So it is a matter of creating the proper stuff around to:
1) use it
2) make is simple to update defconfigs
   A simple extract delta between two config

I'm not up to do that at the moment - but it is doable.
And I would hate to see the defconfig disappear just because
they are so visible in Linus' dirstat.
	Sam
--

[ message continues ]

On Tue, 1 Apr 2008 13:08:57 -0700 (PDT) Linus Torvalds <torvalds@linux-foun=

The downside is that at least some of these were already pending in
maintainers trees for 2.6.26 (among other changes) and so have now caused
(unnecessary) merge conflicts.  Is there some reason that these fixes
can't go through the subsystem trees (especially once we get past rc1 (or
2) and people are gearing up for the next merge window)?

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[ message continues ]

I don't think it's necessarily a bad idea to go through subsystem trees, 
but on the other hand I also don't think it should necessarily be a goal 
in itself.

For example, we had a patch-series from Roland McGrath that was apparently 
almost entirely based on the fact that going through (and getting 
sign-off) from all the architecture maintainers for his ptrace changes was 
just painful as hell for him.

At that point, when there is somebody like Roland who knows the rare and 
odd ptrace interfaces, having him jump through hoops just to go through 
"proper channels" is in my opinion just anti-productive (especially since 
I also think the "political" aspect of the problem causes the actual 
technical side of the patches to suffer - because they are more about 
the politics than about the technology).

So at some point, subsystem mainteinance should also be about picking up 
and handling the changes that come the other way. The kernel development 
isn't a strict hierarchy, and shouldn't be - it's more of a network of 
trust.

In other words, there are people I think are generally trusted across most 
maintenance borders. Al, as far as I'm concerned, is one of them.  
Especially sicne he is also one of the few people who clearly not only 
does run sparse but also looks at the code and actually fixes real bugs 
with byte order etc - regardless of where it is (ie he works across 
drivers, filesystems, an arch-specific code)

In other words, I don't think the borders are so tightly drawn, and the 
same way I trust the individual developers who send me patches (and git 
trees) rather than whatever _companies_ they happen to work, I also tend 
to trust individual developers rather than the _subsystem_ that they 
happen to maintain.

Of course, there's often a rather direct mapping between the two, where 
people naturally have the area they work in. But some people cross across 
any particular area, and while that tends to be unusual, that very much 
includes people like ...
[ message continues ]

Btw - don't get me wrong - we clearly do try to (and should) make merges 
easy, and it's why the kernel source code is generally pretty modular and 
we try to keep things as independent as possible. I'm not at all arguing 
against that.

I'm just trying to explain that at least personally, I just don't see that 
"modularity" and maintainership as a _primary_ issue. The primary issue is 
just the interpersonal trust people build up over time. The modularity and 
trying to keep borders is about practical concerns, and it's important 
too. But it is still secondary, I think. 

			Linus
--

[ message continues ]

What should I sent directly to you and for what should I pray that 
someone picks it up?

E.g. I have a some patches that add missing MODULE_LICENSE's to modules 
and some build fixes (some of the patches already sent to linux-kenrel, 
some are still in my private testing) that IMHO belong into 2.6.25.

I also have sparse fixes and similar stuff pending.

And what about the removal of the broken v850 port I've already sent 
five times to linux-kernel?


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--

[ message continues ]