All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Or Gerlitz <or.gerlitz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Eric Dumazet
	<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] IB/ehca: use kthread_create_on_node
Date: Wed, 8 Feb 2012 13:35:16 -0800	[thread overview]
Message-ID: <CAG4TOxPwcdw+CwyczAVXBqovpECVj8ad+RsraqmchuQdM2bCXw@mail.gmail.com> (raw)
In-Reply-To: <CAJZOPZJtXGq36Hx5BQAc2Q7znErJ-Uaiqs-DaJQ=jCSy49uTiQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Wed, Feb 8, 2012 at 1:26 PM, Or Gerlitz <or.gerlitz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I noted that you typically use the for-next branch of the infiniband
> tree for fixes during
> the 1 < kernN-rc < (say) 6 time and for features during (kernN-rc > 6)
> till kern(N+1)-rc1
>
> 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.

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.

 - R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Roland Dreier <roland@kernel.org>
To: Or Gerlitz <or.gerlitz@gmail.com>
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: Wed, 8 Feb 2012 13:35:16 -0800	[thread overview]
Message-ID: <CAG4TOxPwcdw+CwyczAVXBqovpECVj8ad+RsraqmchuQdM2bCXw@mail.gmail.com> (raw)
In-Reply-To: <CAJZOPZJtXGq36Hx5BQAc2Q7znErJ-Uaiqs-DaJQ=jCSy49uTiQ@mail.gmail.com>

On Wed, Feb 8, 2012 at 1:26 PM, Or Gerlitz <or.gerlitz@gmail.com> wrote:
> I noted that you typically use the for-next branch of the infiniband
> tree for fixes during
> the 1 < kernN-rc < (say) 6 time and for features during (kernN-rc > 6)
> till kern(N+1)-rc1
>
> 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.

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.

 - R.

  parent reply	other threads:[~2012-02-08 21:35 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 [this message]
2012-02-08 21:35           ` Roland Dreier
2012-02-08 22:28           ` Or Gerlitz

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=CAG4TOxPwcdw+CwyczAVXBqovpECVj8ad+RsraqmchuQdM2bCXw@mail.gmail.com \
    --to=roland-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
    --cc=eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=or.gerlitz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /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.