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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
