Let's see if it is a problem in practice. I don't pretend to have the
answer to everyone's problems. I do claim to be implementing all of the
mechanisms such that when we, collectively, figure out how things ought
to work, I can provide higher level tools that do what we need.
So far, I'm hearing you say that it may be bad to have unblessed changes
floating around being integrated into random trees and propogating to
the wrong place at the wrong time. For example, suppose you, Alan,
got a patch and stuck it in your tree and before you discovered that
it was total doggy doo doo, somebody else resynced your tree into their
tree, and that doo doo is not propogating its way around the net. That's
the issue, right?
I agree that that is a bummer and I think that the solution is going to
solve more problems than just the one I discribed. I think the solution
is to have some sort of state associated with a change set (patch); the
default state is something like "bad". I can make the resync tool
not pick up stuff unless it has been marked "good" (this is a little
whilte lie, see below).
I want to do this anyway. The way I envision these tools helping
Linux & Linus work better is like so: changes get developed by some
unknown person "C". Eventually, "C" sends the patch to person "B"
where "B" is one of the Linux lieutenants (i.e., Alan/Dave/whoever).
The patch gets shoved in "B"'s tree and is marked "bad" until "B" can
get around to looking at it and merging it in. The patch is logically
on an unmerged branch. Eventually "B" gets around to doing the merge,
maybe making some additions/deletions to make it work. "B" can then
generate a new patch, complete with full revision history on all changes
that went into the patch, and send it to "A" (aka Linus).
Note that when "B" sent off the patch to "A", the patch is upgrade to
a "pending" in "B"'s tree. Earlier I said that resyncs don't pick
up stuff unless it has been marked "good". That's not quite right.
A resync picks it up, but it is still off on an unmerged branch.
That's the theory, we need some practice. I'm quite happy to discuss
theory til the cows come home, but let's keep it to a minimum. I think
my time is better spent writing the code than discussing the abstract.
--lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu