mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Con Kolivas <kernel@kolivas.org>
Cc: James.Bottomley@steeleye.com, torvalds@osdl.org,
	linux-kernel@vger.kernel.org, len.brown@intel.com,
	jgarzik@pobox.com, tony.luck@intel.com, bcollins@debian.org,
	scjody@modernduck.com, dwmw2@infradead.org, rolandd@cisco.com,
	davej@codemonkey.org.uk, axboe@suse.de, shaggy@austin.ibm.com,
	sfrench@us.ibm.com
Subject: Re: merge status
Date: Wed, 9 Nov 2005 16:25:15 -0800	[thread overview]
Message-ID: <20051109162515.39608d08.akpm@osdl.org> (raw)
In-Reply-To: <200511101116.47034.kernel@kolivas.org>

Con Kolivas <kernel@kolivas.org> wrote:
>
> On Thu, 10 Nov 2005 10:01 am, Andrew Morton wrote:
> > James Bottomley <James.Bottomley@SteelEye.com> wrote:
> > > it's my contributors who drop me in it
> > > by leaving their patch sets until you declare a kernel, dumping the
> > > integration testing on me in whatever time window is left.
> >
> > Yes, I think I'm noticing an uptick in patches as soon as a kernel is
> > released.
> >
> > It's a bit irritating, and is unexpected (here, at least).  I guess people
> > like to hold onto their work for as long as possible so when they release
> > it, it's in the best possible shape.
> 
> I suspect part of that is the concern about whether the code will merge with 
> whatever -mm looks like next. Of course you already do ludicrous amounts of 
> merging, but sometimes you'll just throw it back and say "too many rejects".

Well of course that's not a concern for people who work against the git
trees - scsi/usb/ia64/whatever developers.

But yes, sometimes people's work does clash just too much with things which
are already in subsystem trees or in -mm.  Fortunately it's relatively
rare, and I do think it's best to ask people to develop against latest
-linus rather than against a crazy -mmoving target.

Especially as lots of people are stuck using git, rather than high-tech
patch management technologies ;)


Actually, I disagree with you - it's at 2.6.x release-time that all trees,
including -mm are at their most divergent.  Presumably these developers are
working against the relevant subsystem git tree, and hence can merge into
the subsystem maintainer at any time.

  reply	other threads:[~2005-11-10  0:25 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-09 21:35 Andrew Morton
2005-11-09 21:50 ` James Bottomley
2005-11-09 22:01   ` Linus Torvalds
2005-11-09 22:25     ` James Bottomley
2005-11-09 22:43       ` Linus Torvalds
2005-11-10  7:16         ` Jeff Garzik
2005-11-09 23:01       ` Andrew Morton
2005-11-09 23:09         ` Jesper Juhl
2005-11-09 23:58         ` Linus Torvalds
2005-11-10 13:28           ` Pavel Machek
2005-11-10  0:16         ` Con Kolivas
2005-11-10  0:25           ` Andrew Morton [this message]
2005-11-10  0:24         ` James Bottomley
2005-11-10  8:40         ` Jens Axboe
2005-11-10  8:56           ` Andrew Morton
2005-11-10  9:22             ` Jens Axboe
2005-11-10  9:30               ` Andrew Morton
2005-11-10  9:57                 ` git branches strategy (was Re: merge status) Jeff Garzik
2005-11-10 13:22                 ` merge status Dave Kleikamp
2005-11-10 13:26         ` Pavel Machek
2005-11-14 20:13         ` Bill Davidsen
2005-11-09 22:05 ` Roland Dreier
2005-11-09 22:12 ` Jody McIntyre
2005-11-09 22:18   ` Linus Torvalds
2005-11-09 22:23     ` Jody McIntyre
2005-11-09 22:45       ` Andrew Morton
2005-11-09 22:48       ` Linus Torvalds
2005-11-09 22:13 ` Anton Altaparmakov
2005-11-09 22:48   ` Andrew Morton
2005-11-09 22:58     ` Linus Torvalds
2005-11-09 22:41 ` Russell King
2005-11-10  7:20 ` Jeff Garzik
2005-11-10  8:41 ` Jens Axboe
     [not found] <OF4A6DAD74.A56B078E-ON872570B4.007A77CE-862570B4.007AC8BB@us.ibm.com>
2005-11-09 22:23 ` David Woodhouse
2005-11-09 22:54 Luck, Tony
2005-11-09 23:21 ` Andrew Morton
2005-11-10  7:38 Brown, Len
2005-11-10  7:47 ` Jeff Garzik
2005-11-10  8:19   ` Keith Owens
2005-11-10 17:17 Luck, Tony

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051109162515.39608d08.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=James.Bottomley@steeleye.com \
    --cc=axboe@suse.de \
    --cc=bcollins@debian.org \
    --cc=davej@codemonkey.org.uk \
    --cc=dwmw2@infradead.org \
    --cc=jgarzik@pobox.com \
    --cc=kernel@kolivas.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rolandd@cisco.com \
    --cc=scjody@modernduck.com \
    --cc=sfrench@us.ibm.com \
    --cc=shaggy@austin.ibm.com \
    --cc=tony.luck@intel.com \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®