Re: [RFC] Proposal to address hfi1 UI and EPROM devices

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

On Thu, May 05, 2016 at 08:00:34AM -0400, Dennis Dalessandro wrote:
> On Thu, May 05, 2016 at 09:38:34AM +0300, Leon Romanovsky wrote:
> >>I'd also make a very clear message to driver submitters: Do not
> >>include uAPIs in your initial driver patch set. Those should follow on
> >>as dedicated well identified patches so that they attracted the proper
> >>review.
> >
> >It is hard to agree with this point.
> >It contradicts to development model of submitting whole feature at once
> >and not unconnected piece of code, which someone will be needed to
> >maintain without any real user behind it.
> 
> I think the message really should be that if your driver contains uAPI
> changes those should be in separate patches that are clearly identified. So
> if you have a driver that is developed off-list initially, instead of just
> breaking it up into chunks for submission add another step.
> 
> Something like this:
> 1) Submit patch series which break-ups internally developed code
> 2) Submit patch series with separated out uAPI code
> 3) Submit patch that makes the build go-live
> 
> These can all be submitted together, but with the patches broken up like
> this reviewers can target uAPI code more easily.

At the end, there is no point of accepting (1) without finished review
of (2 and 3). Right now all patch series already have such internal separation
in a slightly different order.

I'm as a reviewer prefer to see whole picture and follow logic from the
general entry point to the specific implementation in driver.

> 
> -Denny

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]