No subject

good to go, but in this case silence for 3 days obviously doesn't
mean that.


> I hope you don't mind fixing that up.

Of course I'll fix it. There's never been a question about that. My
problem is that being told I need to fix it came too late....

> > And that this is the cause of it missing the merge window?
> 
> The regression is the only reason this missed the merge window.  I was ready to
> push the series to -next when Brian pulled the cord.

There's 2-3 months after the merge window to fix minor regressions
like this. More below on this.

> According Linus and Stephens comments we should have content in -next by -rc7.
> Clearly there is some flex in that system but I have no desire to find its
> limit, and I think that this experience proves their point.  Lesson learned!  I
> will be more conservative regarding the merge window in the future.

But that's not the issue I raised - the missing of the release
window is a result of a more fundamental problem - the high
communication latency that prolongs the review process.

And I think being *more conservative* is exactly the wrong way to
fix the problem.

> I'm giving this series some soak time with the new fix.  I can't pull it in
> with the new fix for the regression until we have some testing.  Once we have
> some confidence in it I will push it up to oss.  

You are treating a development tree like it is a precious child that
must be protected from the evil developers that might do something
nasty to it. The development tree is there to benefit the
developers, not the users. We can break the dev tree however we like
as long as it is fixed before the code gets to users (i.e. final
kernel release).  There is nothing wrong with having the master
branch of the xfs development tree having regressions in it.  IOWs,
keeping changes out of the dev tree because "they need soak time" is
exactly the wrong thing to do. Changes should be "soaking" *in the
dev tree*, not in some private black hole that nobody but people at
SGI know about. 

Indeed, the faster the changes get into the dev tree, the more
widespread the testing of the changes is going to be. All my
development use the dev tree as it's base, so unless I merge every
patchset in the list into my current dev tree, I'm not testing
those changes during development. I think the same goes for most
other developers as well. The dev-tree is the tree we use and expect
to find regressions in - that's exactly what a dev tree is for.

Further, holding the changes out of tree can be actively harmful for
co-ordination of work between developers. e.g Brian's prealloc
reclaim work is dependent on this patch set, and while it is held
out of the tree for "soak" he has to privately manage the patches in
his tree, and whenever he posts updates to his work has to reference
the version of the patch set he has based his work on. If it was in
the dev tree, he wouldn't have had to do this.

Hence, IMO, taking a "we can't commit a change until it has passed
some [unknown test] criteria" approach to managing the dev tree is,
at best, misguided and at worst is completely wrong. The dev tree
should move as fast as possible, and regressions be fixed with
commits just as quickly.

This doesn't change how quickly changes get published from the
dev-tree to for-next or for-linus branches - that will still happen
after soak testing occurs.

e.g. A typical release cycle might look like:

Merge window opens:
	- move for-next -> for_linus, pull request
	- move -dev -> for-next

At -rc4 (or earlier and repeatedly if for->next needs fixing):
	- move -dev -> for-next
	- freeze for-next
	- start soak tests for next release
	- merge regressions fixes from for-next -> for-linus, pull
	  request

At -rc6/7 (final -rc):
	- merge regression fixes from -dev -> for-next
	- run final release tests, ready for merge window.

I don't know what your current plan is. It seems, from the outside,
to be completely ad hoc and driven by the realisation that the merge
window is approaching rather than being planned and consistent.
Combine this will long communication latencies, and we have a recipe
for work that was posted a couple of weeks before the merge window
opened missing it because a minor regression wasn't sorted out fast
enough.

If you were committing code the moment it had a reviewed-by tag on
each patch in the series, then committing small patches to fix
regressions and other late review changes, then problems with
latency in commication are minimised. A regression fix with a
"tested-by" tag on it can be committed immediately to the dev tree,
and we move on.  We find the problems faster, we fix them
faster, and we don't miss merge windows going around in circles
trying to work out who is or isn't doing something.

> My understanding is that work for 3.8 should not be added to -next during the
> merge window for 3.7-rc1, so you have plenty of time to address
> Mark&Christoph's concern.

Case in point: you are comingling the release rules for the for-next
branch with the commit rules for the development branch (master). We
control the master branch completely, and it can move independently
of the for-next branch. IOWs, There is no reason why you can't
commit stuff to the master branch during a merge window because that
branch is *completely independent* of the for-next/for-linus
branches and release cycles.

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com