On Thu November 29 2012 00:47:41 Sylwester Nawrocki wrote:

On 11/28/2012 10:29 PM, Dan Carpenter wrote:

quoted

On Wed, Nov 28, 2012 at 08:30:04PM +0100, Sylwester Nawrocki wrote:

quoted

On 11/28/2012 01:22 PM, Dan Carpenter wrote:

quoted

In the end this is just a driver, and I don't especially care.  But
it's like not just this one which makes me frustrated.  I really
believe in linux-next and I think everything should spend a couple
weeks there before being merged.

Couple of weeks in linux-next plus a couple of weeks of final patch
series version awaiting to being reviewed and picked up by a maintainer
makes almost entire kernel development cycle. These are huge additional
delays, especially in the embedded world. Things like these certainly
aren't encouraging for moving over from out-of-tree to the mainline
development process. And in this case we are talking only about merging
driver to the staging tree...

Yeah.  A couple weeks is probably too long.  But I think a week is
totally reasonable.

Agreed, exactly that couple weeks requirement seemed a bit long to me.

quoted

You have the process wrong.  The maintainer reviews it first, merges
it into his -next git tree.  It sits in linux-next for a bit.  The
merge window opens up.  It is merged.  It gets tested for 3 months.
It is released.

I believe what you're describing is true for most subsystems.  At
linux-media the process looks roughly that you prepare a patch and post
it to the mailing list for review.  Regular developers review it, you
address the comments and submit again.  Repeat these steps until
everyone's happy.  Then, when the patch looks like it is ready for
merging it is preferred to send the maintainer a pull request.
Now there can be a delay of up to couple weeks.  Afterwards the patch
in most cases gets merged, with a few possible change requests. However
it may happen the maintainer has different views on what's has been
agreed before and you start everything again.

Yes, and the problem is that the maintainer (Mauro) tends to look at this
close to the merge window, generally leaving you with very little time to
make adjustments.

In all honesty, in this particular case the pull request came in late
because other reviewers asked TI to move the driver to staging because we
thought the driver wasn't quite ready yet.

If it would just be merged as a staging driver, then it would most likely
be sitting in linux-next by now since a few days, well in time for the merge
window. Instead we are having this whole discussion :-(

With a few sub-maintainers recently appointed hopefully there can be
seen some improvement.

I sincerely hope so. Of course, since I'm going to be one of the sub-maintainers
I'm going to see this from the other side as well, so I might get the same
critisism in the future :-)

quoted

It should work as a continuous even flow.  It shouldn't be a rush to
submit drivers right before the merge window opens.  It's not hard,
you can submit a driver to linux-next at any time.  It magically
flows through the process and is released some months later.

It does suck to add a 3 month delay for people who miss the cut off.
Don't wait until the last minute.  In the embedded world you can
use git cherry-pick to get the driver from linux-next.

Yeah, it's not unusual to work with specific -rc tree with multiple
subsystem -next branches on top of it.

It's just those cases where you're told to get feature A in the kernel
release X and it is already late in the development cycle... But it
might just be a matter of planning the work adequately with proper
understanding of the whole process.

Well, it would work if you can rely on patches being reviewed and merged
in a timely manner. Hopefully that will happen when the sub-maintainers
can start next year. It should make everything more predictable.

Regards,

	Hans