All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Stefani Seibold <stefani@seibold.net>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch] proc.txt: Update kernel filesystem/proc.txt documentation
Date: Tue, 9 Jun 2009 14:13:23 -0700	[thread overview]
Message-ID: <20090609141323.aae795a9.akpm@linux-foundation.org> (raw)
In-Reply-To: <1244580807.30614.10.camel@wall-e>

On Tue, 09 Jun 2009 22:53:27 +0200
Stefani Seibold <stefani@seibold.net> wrote:

> Am Dienstag, den 09.06.2009, 12:36 -0700 schrieb Andrew Morton:
> > On Tue, 09 Jun 2009 12:35:58 +0200
> > Stefani Seibold <stefani@seibold.net> wrote:
> > 
> > > This is a patch against the file Documentation/filesystem/proc.txt.
> > > 
> > > It is an update for the "Process-Specific Subdirectories" to reflect 
> > > the changes till kernel 2.6.30. It also introduce the my 
> > > "provide stack information for threads".
> > 
> > Sorry, but it would be much preferable to do this as two patches.  The
> > first fixes up proc.txt and the second adds the
> > stack-information-for-threads material.
> > 
> 
> That is really frustrating. I did everything that you and ingo molnar
> had complained.
> 
> What is wrong with the "provide stack information for threads"? It is a
> very tiny patch which did not harm.
> 
> The only reason to fix and update the proc.txt was that you told me that
> this is the last thing that you miss.

It's more a procedural thing really.  We've learnt that it's best to
avoid mixing more than a single "concept" into a single patch.  For a
whole pile of reasons: reviewability, bisectability, revertability,
testability, etc.

In this case, it's unobvious which parts of the patch were specific to
the stack-information-for-threads changes and which parts were not. 
This makes it hard to review your proposed changes.

> > This is because the two changes are quite conceptually distinct, and we
> > might end up wanting to merge one chage and not the other.
> > 
> 
> Okay, if the other patch will not included than it makes no sense for me
> to get in the other.
> 
> Simple question: will you accept the thread stack info patch or not? If
> yes, i will spent the time to split proc.txt patch.
> 

It looks OK to me now.  If it passes testing and nobody has fatal
objections then yes, I expect it'll be merged in 2.6.31.

The way to organise these changes is

[patch 1/2] fix proc.txt
[patch 2/2] procfs: provide stack information for threads

The second patch will contain a small update to proc.txt.

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Stefani Seibold <stefani@seibold.net>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch] proc.txt: Update kernel filesystem/proc.txt documentation
Date: Tue, 9 Jun 2009 14:13:23 -0700	[thread overview]
Message-ID: <20090609141323.aae795a9.akpm@linux-foundation.org> (raw)
In-Reply-To: <1244580807.30614.10.camel@wall-e>

On Tue, 09 Jun 2009 22:53:27 +0200
Stefani Seibold <stefani@seibold.net> wrote:

> Am Dienstag, den 09.06.2009, 12:36 -0700 schrieb Andrew Morton:
> > On Tue, 09 Jun 2009 12:35:58 +0200
> > Stefani Seibold <stefani@seibold.net> wrote:
> > 
> > > This is a patch against the file Documentation/filesystem/proc.txt.
> > > 
> > > It is an update for the "Process-Specific Subdirectories" to reflect 
> > > the changes till kernel 2.6.30. It also introduce the my 
> > > "provide stack information for threads".
> > 
> > Sorry, but it would be much preferable to do this as two patches.  The
> > first fixes up proc.txt and the second adds the
> > stack-information-for-threads material.
> > 
> 
> That is really frustrating. I did everything that you and ingo molnar
> had complained.
> 
> What is wrong with the "provide stack information for threads"? It is a
> very tiny patch which did not harm.
> 
> The only reason to fix and update the proc.txt was that you told me that
> this is the last thing that you miss.

It's more a procedural thing really.  We've learnt that it's best to
avoid mixing more than a single "concept" into a single patch.  For a
whole pile of reasons: reviewability, bisectability, revertability,
testability, etc.

In this case, it's unobvious which parts of the patch were specific to
the stack-information-for-threads changes and which parts were not. 
This makes it hard to review your proposed changes.

> > This is because the two changes are quite conceptually distinct, and we
> > might end up wanting to merge one chage and not the other.
> > 
> 
> Okay, if the other patch will not included than it makes no sense for me
> to get in the other.
> 
> Simple question: will you accept the thread stack info patch or not? If
> yes, i will spent the time to split proc.txt patch.
> 

It looks OK to me now.  If it passes testing and nobody has fatal
objections then yes, I expect it'll be merged in 2.6.31.

The way to organise these changes is

[patch 1/2] fix proc.txt
[patch 2/2] procfs: provide stack information for threads

The second patch will contain a small update to proc.txt.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-06-09 22:03 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-31 14:58 Detailed Stack Information Patch [1/3] Stefani Seibold
2009-03-31 14:58 ` Stefani Seibold
2009-04-01 19:31 ` Ingo Molnar
2009-04-01 19:31   ` Ingo Molnar
2009-04-02 21:26   ` Stefani Seibold
2009-04-02 21:26     ` Stefani Seibold
2009-06-03 20:34   ` Detailed Stack Information Patch Next Generation Stefani Seibold
2009-06-03 20:34     ` Stefani Seibold
2009-06-03 21:06     ` Andrew Morton
2009-06-03 21:06       ` Andrew Morton
2009-06-04 11:23   ` [patch] procfs: provide stack information for threads Stefani Seibold
2009-06-04 11:23     ` Stefani Seibold
2009-06-04 11:37     ` Andrew Morton
2009-06-04 11:37       ` Andrew Morton
2009-06-04 11:56       ` Stefani Seibold
2009-06-04 11:56         ` Stefani Seibold
2009-06-04 17:57         ` Andrew Morton
2009-06-04 17:57           ` Andrew Morton
2009-06-04 20:21   ` Stefani Seibold
2009-06-04 20:21     ` Stefani Seibold
2009-06-04 21:23     ` Andrew Morton
2009-06-04 21:23       ` Andrew Morton
2009-06-05 19:12       ` Stefani Seibold
2009-06-05 19:12         ` Stefani Seibold
2009-06-05 19:19         ` Andrew Morton
2009-06-05 19:19           ` Andrew Morton
2009-10-02 21:17     ` Andreas Schwab
2009-10-02 21:17       ` Andreas Schwab
2009-10-02 21:44       ` Andreas Schwab
2009-10-02 21:44         ` Andreas Schwab
2009-10-03  6:47         ` Andreas Schwab
2009-10-03  6:47           ` Andreas Schwab
2009-10-03  7:40           ` Stefani Seibold
2009-10-03  7:40             ` Stefani Seibold
2009-10-03 11:33           ` Stefani Seibold
2009-10-03 11:33             ` Stefani Seibold
2009-06-06 10:01   ` [patch] procfs: provide stack information for threads V0.6 Stefani Seibold
2009-06-06 10:01     ` Stefani Seibold
2009-06-09 10:35   ` [patch] proc.txt: Update kernel filesystem/proc.txt documentation Stefani Seibold
2009-06-09 10:35     ` Stefani Seibold
2009-06-09 19:36     ` Andrew Morton
2009-06-09 19:36       ` Andrew Morton
2009-06-09 20:53       ` Stefani Seibold
2009-06-09 20:53         ` Stefani Seibold
2009-06-09 21:13         ` Andrew Morton [this message]
2009-06-09 21:13           ` Andrew Morton
2009-06-10  6:46   ` [patch 1/2] " Stefani Seibold
2009-06-10  6:46     ` Stefani Seibold
2009-06-10  6:46   ` [patch 2/2] procfs: provide stack information for threads V0.7 Stefani Seibold
2009-06-10  6:46     ` Stefani Seibold
2009-06-10  7:20   ` [patch 2/2] procfs: provide stack information for threads V0.8 Stefani Seibold
2009-06-10  7:20     ` Stefani Seibold
2009-06-15 22:01     ` Andrew Morton
2009-06-15 22:01       ` Andrew Morton
2009-06-16  7:14       ` Stefani Seibold
2009-06-16  7:14         ` Stefani Seibold

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=20090609141323.aae795a9.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=stefani@seibold.net \
    /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.