On Mon, May 16, 2011 at 09:39:05AM -0700, Greg KH wrote:
> On Sun, May 15, 2011 at 05:50:54PM +0100, Ben Hutchings wrote:
[...]
> Whereever possible, I take the original commit, as that way I know that
> someone hasn't modified the patch in ways they did not describe (as you
> have done here, and as others have done in the past.) I've been burned
> before, and don't want to again.
>
> That is why, again, I would love just a list of git commit ids, not the
> patches, wherever possible.
>
> And whan you do make a change, like you did above, you need to specify
> it, in detail, what you did and why you did it differently from the
> original commit, in order for me to be able to accept it.
I will admit that I should have been more specific.
> > I think the effect in this case is minor, but now I have to worry whether
> > you are quietly changing other patches.
>
> Now I wonder if you are quietly changing other patches as well, it goes
> both ways :)
I meticulously checked everything I sent you to make sure that every
deviation from an automatic cherry-pick was noted. I formatted and
named every patch according to your convention, and provided a series
file to keep them in order. But you threw that information away.
In general, if someone submits you a patch that doesn't match the
version in mainaline, and they noted it, they probably had a good
reason for it even if it isn't immediately obvious. All I'm asking is
that you respond to that by asking for further explanation rather
than substituting the mainline version.
> For the above problem, please just send me a fix-up patch to apply to
> the .32 tree to resolve the issue.
Will do.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable
