LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86_64 ia32 syscall restart fix
Date: Fri, 29 Feb 2008 14:42:12 -0800 (PST)	[thread overview]
Message-ID: <20080229224212.24A532700FE@magilla.localdomain> (raw)
In-Reply-To: Linus Torvalds's message of  Friday, 29 February 2008 08:26:14 -0800 <alpine.LFD.1.00.0802290814320.17889@woody.linux-foundation.org>

And here I thought I was so good for using coherent English sentences
with proper punctuation and capitalization, not to mention actually
explaining the issues of the change.  I must admit I've been a little
bewildered in the past when Ingo has changed my log entries to be
ungrammatical, eschew standard punctuation, and with an apparent
vendetta on the shift key, not to mention sometimes removed half the
relevant technical detail to boot.

I suppose I shouldn't be surprised at being harangued for making my log
entries too informative.  People love to remove clauses out of the
middle of my code comments too--so they can match the norm of run-on
sentences, I guess.

Most log entries I see are short.  But they really don't explain the
problem being fixed so I know enough about it without digging out some
long mailing list threads.  If that's your preference, then I guess we'll
just have to keep having Ingo remove the text I write.  At least it will
be in the archives from my posting.  (Reading it is the only way I'll
remember myself what details mattered, after a week has gone by.)

If what you want is formulaic log text that always puts blank lines in
between bug description, change description, and change justification, I
can do that.  If there is any place that documents the conventions you
want in log entries, I've overlooked it.

As Ingo alluded to, most of the time my number one focus is to record all
the important facts and decisions before I go back to something else or
knock off for the night.  I hate nothing more than looking at an old
change of mine and not being able to figure out what some of the logic
behind it was.  If there's one thing I can rely on, it's that I'll forget
what I knew the first time until I spend hours the second time
recapitulating the same debugging to find out that I may have had some
sense after all six months back.

Anyway, if the worst push-back on my submissions is a handful
of foreigners telling me how to write English, then I guess
things are ... as they should be. ;-)


As to the question of tagging for backports, I am not really clear on
what the intended criteria are.  Take this bug for example.  It is a
consistent behavior that has existed since the dawn of time (I've only
actually checked back to 2.6.9).  It's wrong, but can't be a surprise
on any system based on a stable release.  It's a regression of the
64-bit kernel vs the native 32-bit kernel, but not a version-to-version
regression.  The fix is straightforward to backport and has very low
risk.  How does all that translate into whether a given stable version
wants a backport or not?


Thanks,
Roland

  parent reply	other threads:[~2008-02-29 22:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29  3:57 Roland McGrath
2008-02-29 15:52 ` Ingo Molnar
2008-02-29 16:26   ` Linus Torvalds
2008-02-29 16:45     ` Ingo Molnar
2008-02-29 17:03       ` Linus Torvalds
2008-02-29 17:17         ` Ingo Molnar
2008-02-29 17:37           ` Ingo Molnar
2008-02-29 21:02             ` Andrew Morton
2008-02-29 21:20               ` Ingo Molnar
2008-03-01  5:48                 ` [stable] " Greg KH
2008-02-29 22:42     ` Roland McGrath [this message]
2008-02-29 23:18       ` Linus Torvalds
2008-03-07 22:56 ` [PATCH] x86_64 ptrace orig_ax on ia32 task Roland McGrath
2008-03-07 23:18   ` Linus Torvalds
2008-03-08  1:37     ` Roland McGrath
2008-03-10 19:19   ` Chuck Ebbert
2008-03-10 19:48     ` Linus Torvalds
2008-03-10 20:01       ` Roland McGrath
2008-03-11  9:32         ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080229224212.24A532700FE@magilla.localdomain \
    --to=roland@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: [PATCH] x86_64 ia32 syscall restart fix' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).