LKML Archive on
help / color / mirror / Atom feed
From: Ingo Molnar <>
To: Linus Torvalds <>
Cc: Roland McGrath <>,
	Andrew Morton <>,
	Thomas Gleixner <>,
Subject: Re: [PATCH] x86_64 ia32 syscall restart fix
Date: Fri, 29 Feb 2008 18:37:05 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

* Ingo Molnar <> wrote:

> and one area where commit messages are totally important IMO is bug 
> forensics. For every regression we find we try to put in the commit ID 
> that broke it. Information like that is vital to have a good (and 
> objective) picture about how bugs get into and get out of the kernel 
> and it also alerts us to change/improve infrastructure if certain 
> categories of bugs happen too often.

another "commit space" feature Thomas and me was thinking about was to 
put in "backport suggestions" for -stable the following way:

   Backport-suggested-by: Ingo Molnar <>

and the -stable tree could then notice it, and once it has been 
backported, they could put in their "done" notifiers via:

   Backported-from: 67ca7bde2e9d3516b5


   Backport-rejected: 67ca7bde2e9d3516b5

This way the act of suggesting backports to the -stable tree (and their 
rejection) could be fully automated, and the answer to the rather 
difficult question:

   "has -stable picked up all backport requests, and if not, why?"

could be scripted up.

A further (small) variation of this scheme: if a fix is noticed to be a 
backport candidate later on, or a user notices that a fix that has gone 
upstream fixes a -stable bug too, this information could be signalled in 
a separate, special, empty commit:

   Backport-suggested-by: 67ca7bde2e9d35, Ingo Molnar <>

this way subsystem maintainers could have a reliable protocol of getting 
fixes integrated into -stable - purely via the commit messages in your 

... but then we decided that handling x86 architecture maintainance is 
work enough already, without us complicating our own life any further 

But the idea is solid nevertheless, and if everyone did it the -stable 
guys would have a much easier life as well :-) [ We could start doing it 
in x86.git if there's general agreement and if the -stable guys 
specifically asked for this. ]


  reply	other threads:[~2008-02-29 17:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29  3:57 [PATCH] x86_64 ia32 syscall restart fix 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 [this message]
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
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:

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

  git send-email \ \ \ \ \ \ \ \

* 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 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).