On Tue, 2008-02-12 at 09:09 -0800, Linus Torvalds wrote:
quoted text
>  (a) create a base tree with _just_ that fundamental infrastructure change,
>      and make sure that base branch is so obviously good that there is no 
>      question about merging it.

The problem is how do we use a?  Usually we need to track your -rc tree
as our fixes go in ... some of which affect our development trees.

If we stick with (a) as the base, we don't get to pull in the fixes in
your tree.  If we use your tree we have to pull in (a) creating n
different merge points for the n different upstream trees..

quoted text
> (b) tell other people about the reason for the infrastructure change, and 
>      simply allow others to merge it. You don't have to wait for *me* to 
>      open the merge window, you need to make sure that the people that get 
>      impacted most can continue development!

Yes, this is effectively what I did with the post merge SCSI tree.
However, if you do this rebasing becomes a fact of life because you need
to rebase out all the dependencies you have before you merge (in fact,
it's a good way of checking whether your dependencies have been merged
yet or not, seeing what survives a rebase).

James


--
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/