Messages in this thread | | | Date | Tue, 19 Feb 2008 22:06:46 +0200 | From | Adrian Bunk <> | Subject | Re: [GIT PATCH] split up feature-removal-schedule.txt |
| |
On Tue, Feb 19, 2008 at 11:49:10AM -0800, Greg KH wrote: > On Tue, Feb 19, 2008 at 11:34:22AM -0800, Randy Dunlap wrote: > > On Tue, 19 Feb 2008 11:07:45 -0800 Greg KH wrote: > > > > > On Wed, Feb 13, 2008 at 10:13:42AM -0800, Linus Torvalds wrote: > > > > > > > > > > > > On Wed, 13 Feb 2008, Joe Perches wrote: > > > > > > > > > > MAINTAINERS is the most frequently patched file > > > > > > > > Almost all of them merge perfectly, with no problems what-so-ever. And the > > > > merge conflicts, when they happen, are generally really trivial, and never > > > > cause any subtle run-time bugs even if they were to happen. > > > > > > > > So in that sense, I think both MAINTAINERS and the deprecation schedule > > > > are totally uninteresting. Yes, they have merge conflicts. But those merge > > > > conflicts are really really easy to handle. > > > > > > Yes, they are easy to handle, but for trees that have to deal with these > > > merge issues all the time, they are a pain (hit this one again today.) > > > It takes a few minutes to fix up the resolution by hand (using either > > > git or quilt), as we do want the new addition to be in the file, so by > > > splitting it up, it makes our (the sub-tree maintainers) lives easier. > > > > > > I've never had a problem with the MAINTAINERS file, as it is pretty big > > > and conflicts for me seem to never happen, but the feature-removal file > > > does cause problems as it changes over time and things need to get added > > > and removed. > > > > > > Also, there are already remants of a bad-merge in that file, which > > > somehow sneaked through. > > > > > > Yes, these files can not cause kernel bugs, but they are semi-important > > > to at least get correct. So I'd ask you to reconsider for the > > > feature-removal stuff at the very least. > > > > > > If you do, the git tree is still there at: > > > master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ > > > > > > to pull from :) > > > > Alternatively, since they are easy to fix, I'll volunteer to fix them > > (after notified of problems :). (and not split up the file) > > Well, the problem is that when someone sends me a patch, I have to do > the fixups by hand (same goes for Jeff), in order for you, or anyone > else to even be able to see the patch show up anywhere. > > That's why having this split up will help make the sub-tree maintainers > lives easier, it's not an issue for Andrew and Linus, as usually the > problem is all fixed up by the time the patch makes it there :)
I'm not sure whether it's feasible, but there's a tricky alternative solution: Adding or removing entries must not add or remove any empty or dash lines.
With this rule, all other entries would be outside of the context of patches touching feature-removal-schedule.txt...
> thanks, > > greg k-h
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
| |