Re: 2.6.12-mm1

[Jean Delvare <khali@linux-fr.org>]

Hi Andrew,

> > No, Mauro. This patch is necessary to fix something YOU just broke
> > with your previous patch. So please learn how to make correct
> > patches that don't randomly revert previous changes. This will make
> > everyone's life easier, including Andrew's, Greg's and mine.
> 
> Yup.  This sort of thing often happens when teams run parallel CVS
> trees.

I don't see how this is relevant. People may use whatever they want as
their playground when working on the code, but are required to provide
clean patches when they want their changes to be merged in. I don't even
ask for patches against a bleeding-edge tree - just *clean* patches, not
reverting anything or otherwise including unwanted changes. Andrew, I
believe you have enough work to do as it is without adding the burden of
doubling the amount of patches you have to work with, and requiring you
to merge patches yourself before you send them to Linus.

> I don't think anything needs to be done by Mauro in this case.  Once
> Greg's patches are merged up I'll fold the two fixes into the v4l
> patches then send them off to Linus and everything will come out
> squeaky clean.

There *is* something Mauro needs to do, that is, provide clean patches.
The fact that they revert a change from Greg's patches is irrelevant
here. It could as well be in Linus' tree already (it will be soon).

What I suspect Mauro did is: start from kernel tree X, work on it, then
provide a diff against tree X+1 and X + his own changes. Whether X is
some CVS repository and X+1 is an official tree doesn't really matter.
What matters is that this working model is fundamentally broken. You
must *always* generate patches between X and X + your changes, whatever
X is. I don't think it's really hard to understand, and do.

Thanks,
-- 
Jean Delvare
-
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/