On Sat, 09 Dec 2006 23:05:58 +0100 Stefan Richter <[EMAIL PROTECTED]> wrote:
> > fs/ocfs2/dlm/dlmrecovery.c | 6 +++--- > > fs/ocfs2/localalloc.c | 2 +- > > fs/ocfs2/slot_map.c | 2 +- > > fs/ocfs2/suballoc.c | 6 +++--- > > fs/ocfs2/super.c | 6 +++--- > > fs/ocfs2/vote.c | 4 ++-- > > include/linux/gameport.h | 2 +- > > kernel/relay.c | 4 ++-- > > net/sunrpc/svc.c | 2 +- > > sound/pci/hda/patch_realtek.c | 4 ++-- > > 34 files changed, 91 insertions(+), 91 deletions(-) > > This should really be split up and submitted separately. All the subsystems > are constantly changing. Although merging these kinds of changes manually > after eventual conflicts, it's still manual work for the maintainers which > would be avoided by a little bit extra work by the submitter. A maintainer > could get a merge conflict on a 100 lines long hunk because of an 8 lines > long hunk that got upstream on a different route. Well actually.. With a patch like this, if any hunk clashes with a subsystem maintainer's tree I'll usually just drop that hunk, or I'll fix it up so that it applies to the maintainer's devel tree and won't merge it until the maintainer has merged with mainline. Or, if the maintainer is being sluggish, I'll just drop the problematic hunk and I'll merge the rest with Linus. IOW, what I merge with Linus is that part of the patch which doesn't conflict with any of the subsystem trees. Of course, if your subsystem tree isn't in -mm then you lose. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
