Re: linux rdma 3.14 merge plans

[Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>]

On Thu, Jan 16, 2014 at 11:42:19PM +0200, Or Gerlitz wrote:
> On Thu, Jan 16, 2014 at 11:37 PM, Greg Kroah-Hartman
> <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> > On Thu, Jan 16, 2014 at 01:14:12PM -0800, Nicholas A. Bellinger wrote:
> >> On Thu, 2014-01-16 at 12:13 -0800, Roland Dreier wrote:
> >> > > On Mon, 2014-01-13 at 12:32 -0800, Nicholas A. Bellinger wrote:
> >> > > > Hi Roland & Co,
> >> > > > Just curious if your planning to take a look at this series soon for
> >> > > > v3.14 code..?
> >> > > >
> >> > > > As you might imagine, I'd like to see it merged this round in order to
> >> > > > move forward on iser-target protection for v3.15.
> >> > > >
> >> > > > Are there any specific issues that you'd like to see addressed for an
> >> > > > initial merge..?
> >> >
> >> > I haven't really had a chance to look at the new API and decide if it
> >> > makes sense as the way to expose these features.  Have you looked at
> >> > the new kernel API?  Any thoughts?
> >>
> >> I've reviewed the API from the perspective of what's required for
> >> implementing protection support in iser, and currently don't have any
> >> recommendations or objections beyond what has been proposed by Sagi & Co
> >> in PATCH-v4 code.
> >>
> >> > How does it compare with how other subsystems have exposed protection
> >> > info?
> >> >
> >>
> >> So there is not a interface in SCSI land for interacting (directly) with
> >> hardware protection support, as it's primarily just telling SCSI what
> >> protection modes are supported while the rest is implemented in vendor
> >> specific firmware interfaces.  (CC'ing MKP)
> >>
> >> > Right now I'm dealing with fixing the fallout from picking up the "IP
> >> > addressing for IBoE" and other patch sets that were supposedly "ready
> >> > to merge for a long time" so I'm not sure I'll get to the protection
> >> > changes in time for 3.14.
> >> >
> >>
> >> Pretty please for v3.14..?
> >
> > It's _really_ late in the development cycle for new stuff for 3.14.  My
> > trees have been closed for almost a week now, for major stuff, and for
> > anything else for a few days now.  It would be good if you could get
> > your patchsets into the 0-day testing bot earlier to shake out any build
> > issues that might happen with them, please work with that developer to
> > help make the merging of the code easier.
> 
> Greg,
> 
> The T10 patches were posted whole three months ago (V0 Oct 15th). I
> don't see why another cycle should get lost just because there was no
> maintainer feedback on them throughout this whole period. There's
> enough time for us to fix things that will show up in the testing bot
> before Roland sends his pull request over the two weeks merge window.

There's the rule that things need to be in linux-next for a week or so
to shake things out before going to Linus, and that new things can't be
added to a maintainer tree after Linus does a release before -rc1 is
out.  We can't break those rules unless you want to answer to the
linux-next developer and Linus for it.

Yes, I know your patches have been pending for a long time, this merge
window was tough in that it covered two major holidays, your patches
aren't the only thing that is going to miss 3.14 by a long-shot, there
are lots of other developers who also didn't get stuff in due to
maintainers taking long vacations.

Which is fine, and is why we have 3 month release cycles, there's
nothing wrong with waiting for 3.15 if there are build issues that are
cropping up this late in the cycle.  That's why I suggest you get your
trees into the 0-day bot test systems, so that a maintainer has a
semblance of confidence that the build will not break, and the "obvious"
security issues are resolved, if they take your patches.

thanks,

greg k-h
--
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