All of lore.kernel.org
 help / color / mirror / Atom feed
From: Or Gerlitz <or.gerlitz@gmail.com>
To: Roland Dreier <roland@kernel.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	Sean Hefty <sean.hefty@intel.com>,
	linux-rdma@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] IB/ehca: use kthread_create_on_node
Date: Thu, 9 Feb 2012 00:28:46 +0200	[thread overview]
Message-ID: <CAJZOPZJs6KpcRTc2HH0rEiParY=ZQUkXZmoUzh2OwZw9+rDjsQ@mail.gmail.com> (raw)
In-Reply-To: <CAG4TOxPwcdw+CwyczAVXBqovpECVj8ad+RsraqmchuQdM2bCXw@mail.gmail.com>

On Wed, Feb 8, 2012 at 11:35 PM, Roland Dreier <roland@kernel.org> wrote:
> On Wed, Feb 8, 2012 at 1:26 PM, Or Gerlitz <or.gerlitz@gmail.com> wrote:

>> [...] This means that the window of time when features are actually accepted
>> into your tree is kind of very limited. Would it be possible to
>> maintain two branches: for-next and (say) rc-fixes, such that
>> practically patches are reviewed/accepted to for-next at almost all times?

>> BTW I see that networking and scsi maintainers use two trees (net/net-next)
>> and (scsi-misc/scsi-rc-fixes), maybe it would be eaiser for you go this way?

> It's not really an issue of not having a tree to put things into.  It's
> more that the window when I actually review major things is not
> as big as perhaps it should be.

> So I generally try to get fixes in expeditiously because they're
> easy to deal with, whereas I only dedicate time to merging bigger
> things when I feel the pressure of the impending merge window.

but bigger things need bigger time to deal with... but even before we
address that -

> I do usually have some small patches that are fine for the next window
> but which I have only marked "to apply" in my mailbox, which it
> might be a good idea to apply sooner so they get more -next tree coverage.

Yep, having a branch where patches you accept are applied sooner
rather then later,
will be a little but surely nice && important step in the right
direction... it would be great to have this, could you make that
happen?

Also, to except for patches which you reviewed and willing to accept,
it happens that Sean Hefty who is also a maintainer, reviews patches
and provides his reviewed-by signature. I would say such patches could
(should) go to that branch as well and not wait to the pressure of the
impending merge window.

How does all this sound?

Or.

      reply	other threads:[~2012-02-08 22:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-29  7:15 [PATCH] IB/ehca: use kthread_create_on_node Eric Dumazet
2011-07-29  7:15 ` Eric Dumazet
2011-07-29 17:10 ` Roland Dreier
2011-07-29 17:10   ` Roland Dreier
     [not found]   ` <CAL1RGDXJzW7e2LTyex1EZXSLBdB_xmcBvBiiS2XKL-5qUCOQ1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-07-29 17:39     ` Hoang-Nam Nguyen
2011-07-29 17:39       ` Hoang-Nam Nguyen
2012-02-02 11:12 ` Eric Dumazet
2012-02-02 11:12   ` Eric Dumazet
2012-02-02 17:08   ` Roland Dreier
2012-02-08 21:26     ` Or Gerlitz
     [not found]       ` <CAJZOPZJtXGq36Hx5BQAc2Q7znErJ-Uaiqs-DaJQ=jCSy49uTiQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-02-08 21:35         ` Roland Dreier
2012-02-08 21:35           ` Roland Dreier
2012-02-08 22:28           ` Or Gerlitz [this message]

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='CAJZOPZJs6KpcRTc2HH0rEiParY=ZQUkXZmoUzh2OwZw9+rDjsQ@mail.gmail.com' \
    --to=or.gerlitz@gmail.com \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=roland@kernel.org \
    --cc=sean.hefty@intel.com \
    /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.