public inbox for linux-next@vger.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: akpm@linux-foundation.org
Cc: alan@lxorguk.ukuu.org.uk, greg@kroah.com, sfr@canb.auug.org.au,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: is the weeks before -rc1 the time to really be working on -next?
Date: Wed, 15 Oct 2008 16:56:27 -0700 (PDT)	[thread overview]
Message-ID: <20081015.165627.46518276.davem@davemloft.net> (raw)
In-Reply-To: <20081015164139.ebcd24c6.akpm@linux-foundation.org>

From: Andrew Morton <akpm@linux-foundation.org>
Date: Wed, 15 Oct 2008 16:41:39 -0700

> On Wed, 15 Oct 2008 16:08:21 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
> 
> > And just like networking we could have Stephen treat the -mm
> > GIT tree as "important" which roughly means that other conflicting
> > trees will be knocked out of a -next release in deference to -mm.
> > 
> > Those people will have to fix their stuff, not you.  And you'll
> > always therefore get coverage in -next.
> 
> Yes, but then people would end up being based on linux-next, and that's
> a pretty rubbery target with all the rebasing and trees getting
> dropped, etc.  And they'd accidentally end up having to actually
> compile and run linux-next, shock-horror-oh-the-humanity.

That's not the idea actually.

The idea is that you run your tree strictly just like any other
subsystem maintainer.  Your tree is a clone of Linus's and you
put -mm stuff in on top of that.  Full stop.

So anyone can work on -mm independent of -next.  Just like networking,
PCI, INPUT, or any other subsystem.  There is no reason in my mind to
treat -mm specially, anything else is just pain for the people that
could contribute and help.

> I doubt if the world would end if we just stopped trying to run any of
> these uber-trees.  Everyone bases their work on mainline and then
> everything goes smash/bang/curse during the merge window.  It wouldn't
> be pretty, but it'd sure make people merge their trees promptly ;)

I think this aspect is interesting actually.

For folks that use stable GIT trees, we can cross polinate ourselves
to resolve merge problems quite simply, and I have seen this happen
already in the most recent cycle.

Things go smoothly for people that maintain stable GIT trees.  The
more stuff you touch the more important this is.

The "I rebase my tree ever 3 hours" stuff only works if you are
strictly working in a certain area and have no contributors you care
about.

But I even question this situation, no piece of code is an island in
the kernel and even well contained drivers want to modify some
infrastructure from time to time.

      parent reply	other threads:[~2008-10-15 23:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-15 17:40 is the weeks before -rc1 the time to really be working on -next? Greg KH
2008-10-15 20:04 ` Geert Uytterhoeven
2008-10-15 20:30   ` Greg KH
2008-10-15 21:56 ` Andrew Morton
2008-10-15 22:08   ` Rafael J. Wysocki
2008-10-15 22:36   ` Alan Cox
2008-10-15 22:53     ` Andrew Morton
2008-10-15 23:08       ` David Miller
2008-10-15 23:41         ` Andrew Morton
2008-10-15 23:53           ` Tony Luck
2008-10-15 23:56           ` David Miller [this message]

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=20081015.165627.46518276.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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