On Tue, Feb 19, 2008 at 11:49:10AM -0800, Greg KH wrote:
quoted text
> 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...

quoted text
> 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

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/