[PATCH 01/23] staging/lustre/clio: don't ignore layout on writeback

Peng Tao bergwolf at gmail.com
Mon Jun 3 13:35:24 UTC 2013


On Mon, Jun 3, 2013 at 11:15 AM, Greg Kroah-Hartman
<gregkh at linuxfoundation.org> wrote:
> On Mon, Jun 03, 2013 at 11:02:42AM +0800, Peng Tao wrote:
>> Hi Andreas and Greg,
>>
>> Sorry for top posting, but the text is mixed with Andreas' reply. And
>> I want to confirm with you what to keep/drop in the commit messages.
>>
>> Currently, we have following non-sob/rb lines:
>> 1. Intel-bug-id:
>> 2. Lustre-commit:
>> 3. Lustre-change:
>> 4. one blank line seperating original commit message from the added
>> lines for kernel commit
>> 5. one line of comment for upstream change explanation
>>
>> I think we all agreed that we will at least keep 1 and 3, with 1
>> changed to full URL.
>
> That's fine.
>
>> So I'd like to confirm with you what to do with
>> the others. I think both of you have good reasoning about the format
>> of commit message. But we need to draw a conclusion to move forward,
>> right? :)
>>
>> Greg, since Andreas' last reply was mixed with quotes, I
>> copied/reformated them bellow so that you can read easier.
>>
>> > Lustre-commit: 3141db609d95d379761e3b54899618b4037d38f6
>> >
>> >
>> > Or this one?
>> >
>> >
>> [Andreas] This is the Lustre git commit hash, so we can track the
>> commits which have been merged into the kernel tree.
>
> Ok, but we don't care at all about that, and neither does the rest of
> the world, so please don't do it.  Numberous groups have tried to do
> this with other patches, and it's been rejected every time, please don't
> try to do it again.
>
>> > Lustre-change: http://review.whamcloud.com/6154
>> >
>> >
>> > This one is at least informative, so it can stay, if you really want it
>> > there, but the others are not relevant to anyone outside of your
>> > internal development environment, so do not belong in a Linux kernel
>> > commit message, sorry.
>> >
>> >
>> [Andreas] Per Documentation/SubmittingPatches: "Some people also put
>> extra tags at the end.  They'll just be ignored for now, but you can
>> do this to mark internal company procedures or just point out some
>> special detail about the sign-off."
>
> Well, I don't accept patches like that, and I really don't know anyone
> else who does, sorry.
>
> The information in a patch has to be relevant to _anyone_ who reads it.
> So it needs to be public urls only, sorry.
>
>> > [updated for upstream kernel submission]
>> >
>> >
>> > What's with the line break and this [] comment?  We don't care about
>> > that.
>> >
>> >
>> [Andreas] Also per SubmittingPatches:
>> [Andreas] "...it is recommended that you add a line between the last
>> Signed-off-by header and yours, indicating the nature of your changes.
>> While there is nothing mandatory about this, it seems like prepending
>> the description with your mail and/or name, all enclosed in square
>> brackets, is noticeable enough to make it obvious that you are
>> responsible for last-minute changes."
>>
>> [Andreas] I guess we can remove the obvious ones (minor or no changes
>> from the original patch), and improve the ones with substantive
>> changes to be more descriptive.
>
> Yes, please do so.
>
> Personally, I don't like seeing that in the signed-off-by: area, I'd
> recommend to put it above them all, in [].
>
Thanks for confirming. I'll update and resend.

--
Thanks,
Tao



More information about the devel mailing list