[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1202797308.10004.41.camel@brick>
Date: Mon, 11 Feb 2008 22:21:48 -0800
From: Harvey Harrison <harvey.harrison@...il.com>
To: David Miller <davem@...emloft.net>
Cc: arjan@...radead.org, greg@...ah.com, sfr@...b.auug.org.au,
linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
linux-arch@...r.kernel.org, akpm@...ux-foundation.org,
torvalds@...ux-foundation.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))
On Mon, 2008-02-11 at 22:11 -0800, David Miller wrote:
> From: Arjan van de Ven <arjan@...radead.org>
> Date: Mon, 11 Feb 2008 21:17:51 -0800
>
> > this is why you need specific trees for just the API change
>
> API trees don't work, just like other changes they will have
> interdependencies on things like fixups, cleanups, etc.
>
> This is why, with the networking, we've just tossed all of the network
> driver stuff in there too. I can rebase freely, remove changesets,
> rework them, etc. and this causes a very low amount of pain for Jeff
> Garzik and John Linville.
>
> This may or not be a legitimate thing to do with other heavily
> dependant subsystems.
I was hoping that eventually certain pieces will stop moving and will
become a base that we can ask people to rebase on top of. Perhaps
even asking that stuff destined for 2.6.x+1 go into a -next branch
and the more devel quality stuff go into a -mm branch that is based
off of their -next branch. Gradually stuff would move from -mm
to -next, getting constantly integrated against other peoples' stuff.
More disruptive changes could go in and gradually as people rebase their
trees the conflicts would hopefully get less painful.
But, let's see how things go.
Harvey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists