From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "\"Jan H. Schönherr\"" <schnhrr@cs.tu-berlin.de>
Cc: Joe Perches <joe@perches.com>,
Andrew Morton <akpm@linux-foundation.org>,
Kay Sievers <kay@vrfy.org>,
linux-kernel@vger.kernel.org,
Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [PATCH v2 00/14] printk() fixes, optimizations, and clean ups
Date: Fri, 7 Dec 2012 07:04:48 -0800 [thread overview]
Message-ID: <20121207150448.GC20369@kroah.com> (raw)
In-Reply-To: <50C1D758.1080007@cs.tu-berlin.de>
On Fri, Dec 07, 2012 at 12:47:36PM +0100, "Jan H. Schönherr" wrote:
> Am 07.12.2012 03:51, schrieb Joe Perches:
> > On Thu, 2012-12-06 at 16:19 -0800, Andrew Morton wrote:
> >> On Thu, 06 Dec 2012 15:37:30 -0800
> >> Joe Perches <joe@perches.com> wrote:
> >>> Can you please pick this up for -next now and I'll
> >>> redo my patches against -next for -rc1 so I'm not
> >>> delayed until 3.9?
> >>
> >> It would be better to do things in the other order.
> >>
> >> a) Your patches perform mainly code-movement which doesn't cause
> >> functional changes. Jan's patches are functional changes which
> >> require more thought and testing and possible fixups.
> >
> > Fine by me. Jan?
>
> No problem.
>
> I agree with Andrew, that patches 9 to 14 could use indeed some
> more eyeballs.
>
> Patches 1 to 8 are more straight-forward, and I would consider
> these ready. However, they are also those, where I probably won't
> have any trouble rebasing them on top of your changes.
>
>
> Anyway. Until now I always thought my patches will end up in the
> queue of some maintainer, so that I don't have to bother about
> _when_ posting my patches. Therefore: when should I repost a
> version rebased on top of Joe's changes?
You are correct, I'll end up queuing these up to my tree when 3.8-rc1 is
out, they will live in linux-next until 3.8-final is out, and then go to
Linus for 3.9-rc1. Right now, my trees are frozen due to the merge
window about to open up. Your patience is appreciated.
thanks,
greg k-h
next prev parent reply other threads:[~2012-12-07 15:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-06 17:05 [PATCH v2 00/14] printk() fixes, optimizations, and clean ups Jan H. Schönherr
2012-12-06 17:05 ` [PATCH v2 01/14] printk: drop ambiguous LOG_CONT flag Jan H. Schönherr
2012-12-06 17:05 ` [PATCH v2 02/14] printk: use saved timestamp for temporarily buffered message Jan H. Schönherr
2012-12-06 17:06 ` [PATCH v2 03/14] printk: reclaim cont buffer immediately for fully printed messages Jan H. Schönherr
2012-12-06 17:06 ` [PATCH v2 04/14] printk: do not add unnecessary newlines to the continuation buffer Jan H. Schönherr
2012-12-06 17:06 ` [PATCH v2 05/14] printk: reuse reclaimed continuation buffer immediately Jan H. Schönherr
2012-12-06 17:06 ` [PATCH v2 06/14] printk: move wake_klogd-check out of the loop Jan H. Schönherr
2012-12-06 17:06 ` [PATCH v2 07/14] printk: let cont_print_text() reuse existing code Jan H. Schönherr
2012-12-06 17:06 ` [PATCH v2 08/14] printk: refactor locking in console_unlock() Jan H. Schönherr
2012-12-06 17:06 ` [PATCH v2 09/14] printk: retain unknown log-level until cont_add()/log_store() Jan H. Schönherr
2012-12-06 17:06 ` [PATCH v2 10/14] printk: track previously logged message in log_store() Jan H. Schönherr
2012-12-06 17:06 ` [PATCH v2 11/14] printk: avoid glitches in console output Jan H. Schönherr
2012-12-06 17:06 ` [PATCH v2 12/14] printk: encode formatting in message flags Jan H. Schönherr
2012-12-06 17:06 ` [PATCH v2 13/14] printk: drop now useless tracking of previous " Jan H. Schönherr
2012-12-06 17:06 ` [PATCH v2 14/14] printk: refactor continuation buffer handling Jan H. Schönherr
[not found] ` <20121206133907.37c255e9.akpm@linux-foundation.org>
2012-12-06 23:37 ` [PATCH v2 00/14] printk() fixes, optimizations, and clean ups Joe Perches
[not found] ` <20121206161943.78633125.akpm@linux-foundation.org>
2012-12-07 2:51 ` Joe Perches
2012-12-07 11:47 ` "Jan H. Schönherr"
2012-12-07 15:04 ` Greg Kroah-Hartman [this message]
2012-12-07 15:42 ` Joe Perches
2012-12-07 15:58 ` Frederic Weisbecker
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=20121207150448.GC20369@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=joe@perches.com \
--cc=kay@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=schnhrr@cs.tu-berlin.de \
--cc=sfr@canb.auug.org.au \
/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.