From: Greg KH <greg@kroah.com> Date: Tue, 12 Feb 2008 11:15:53 -0800BTW, there are some things we can do to with the kernel structure to help a lot of really idiotic cases. 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. Little things like this would go a long way to eliminating merge hassles. For example, with #2, when a driver is added it would only every add files never edit existing files. Merge conflicts are impossible unless two new drivers try to use the same file names. :-) --
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Andy Whitcroft | clam |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Trent Piepho | [PATCH] [POWERPC] Improve (in|out)_beXX() asm code |
git: | |
| David Miller | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
