On Mon, Jun 3, 2013 at 11:15 AM, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
