From: "Jan Beulich" <jbeulich@novell.com>
To: "Ingo Molnar" <mingo@elte.hu>
Cc: <jeremy.fitzhardinge@citrix.com>, <tglx@linutronix.de>,
<linux-kernel@vger.kernel.org>, <hpa@zytor.com>
Subject: Re: [PATCH] x86-64: fix HYPERVISOR_update_descriptor()
Date: Thu, 12 Mar 2009 11:51:59 +0000 [thread overview]
Message-ID: <49B9056F.76E4.0078.0@novell.com> (raw)
In-Reply-To: <20090312113520.GA8353@elte.hu>
>>> Ingo Molnar <mingo@elte.hu> 12.03.09 12:35 >>>
>* Jan Beulich <jbeulich@novell.com> wrote:
>> I'm confused: What point is there to add a textual description
>> that matches the subject? [...]
>
>For example, under what circumstances did you trigger the bug,
>how widely does it affect people, how did you test it. You are
>sending patches very close to the 2.6.29 release, and your
>commit log is non-existent.
>
>Yes, i can figure out what the patch does, but that is not the
>point.
>
>The point is for you to be forthcoming with such information and
>trying to be helpful to the maintenance process, by properly
>describing changes, by describing how you found the bug, how you
>tested the fix, how significant you find the fix, etc.
>
>I.e. try to emit the information you have about this _already_,
>and generously so, instead of hiding it and forcing others to
>recover it.
Hmm, I'm really just following what I see from many others. And I have
to admit that there are [tiny] patches that really don't need much
explanation (and I often find quite the inverse - huge patches that have
[almost] no description).
>>It might be a small work for me to recover it and
>>put it into the changelog, but many of your past patches showed
>>such a pattern and such overhead mounts up quickly.
I'm sorry for that - I simply wasn't aware I'm causing you to do extra
work. I usually try to be as verbose with patches as seems necessary
to me - after all I have no other way to judge ho much is too little or
too much.
>> [...] And where is the need for an impact line documented
>> (clearly neither SubmitChecklist no SubmittingPatches have any
>> occurrence of the word impact), i.e. what are the valid values
>> to chose from?
>
>See:
>
> http://lkml.org/lkml/2008/10/28/67
Thanks. Would certainly be helpful to put into Documentation/ if this is
meant to be more than just a personal requirement of yours.
Jan
next prev parent reply other threads:[~2009-03-12 11:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-12 10:36 [PATCH] x86-64: fix HYPERVISOR_update_descriptor() Jan Beulich
2009-03-12 10:54 ` Ingo Molnar
2009-03-12 11:25 ` Jan Beulich
2009-03-12 11:35 ` Ingo Molnar
2009-03-12 11:51 ` Jan Beulich [this message]
2009-03-12 15:02 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2008-12-16 11:37 Jan Beulich
2008-12-16 17:55 ` Jeremy Fitzhardinge
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=49B9056F.76E4.0078.0@novell.com \
--to=jbeulich@novell.com \
--cc=hpa@zytor.com \
--cc=jeremy.fitzhardinge@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.