On Tue, Feb 12, 2008 at 06:20:12PM -0800, David Miller wrote:
quoted text
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Tue, 12 Feb 2008 18:06:13 -0800
> 
> > So perhaps a better workflow would be keep the linux-next trees all
> > messy, and then each developer can consolidate, rebase, join and
> > drop things prior to sending their individual trees to Linus.
> 
> We could do that, but I believe Linus's main point is that if we go
> and change the trees then in the end we're merging in something
> different than what was actually tested, namely all the original trees
> as merged into linux-next.
> 
> And I kind of agree with that.

	Make the distinction earlier.  With ocfs2 and configfs (we got
this scheme from Jeff), we keep the topic branches as "unsafe" - that
is, officially rebaseable .  We merge them all into a big "ALL" branch,
which is also "unsafe".  Andrew pulls this for -mm, and it gets tested 
here.  If there is a brown-paper-bag problem, we can tell the original
author to fix it.  Then we re-pull the topic - effectively a rebase.
The ALL is also rebased.  But that's Ok, it will never go towards Linus.
	When a topic is considered worthy of going upstream, we pull it
to a branch called "upstream-linus".  This branch is *NEVER* rebased.
Now that the topic is in upstream-linus, the original topic branch can't
be rebased either.  So any fixes to that topic going forward will stay
in the history.  Since that topic was pulled into ALL for testing, we
are using the identical commits that got tested.

Joel

-- 

"I have never let my schooling interfere with my education."
        - Mark Twain

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/