> (Usually I plan a track and submit individual steps.
> When they get applied I continue.
> If not, there is not need to waste time on the rest.)
As someone who is on the receiving end of this process I must say that it
is not comfortable.
It really helps to be able to see the whole thing laid out all at the same
time. So we can see that it works, so that we can see that the end result
is the right one, etc.
Whereas receiving a long drawn out trickle of patches is quite confusing.
One doesn't know where it is leading, nor where it will end, nor when to
get down and actually start testing it, etc. Nor whether this ongoing
churn is stomping on someone else's development effort.
And there is the risk that you get halfway through and then suddenly "no
way, we don't want to do that". Then what? Argue? Revert?
So for everyone except the guy who's writing the code it is best to have
all the work in place and reviewable at the same time.
For the author, yes, there is a risk that more code than necessary will be
tossed away. We can minimise that by discussing things beforehand, getting
understanding and agreement from the relevant people on the intended
direction. I think we have done that for cryptoloop. We still have not
really done it for 64-bit dev_t.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:17 EST