Re: [PATCH 11/14] block: implement and use [__]blk_end_request_all()

[Bartlomiej Zolnierkiewicz]

On Sunday 15 March 2009, Jens Axboe wrote:
> On Sun, Mar 15 2009, Bartlomiej Zolnierkiewicz wrote:
> > > > > > Thanks for the hint but it sounds like a major pain once you hit some
> > > > > > changes touching the same code areas that block patches do...
> > > > > > 
> > > > > > Besides this is guaranteed to inrease the workload on my side so it
> > > > > > won't happen simply because of -ENOTIME.
> > > > > 
> > > > > When things collide, it is more work for everyone. But such is life for
> > > > > middle/core layer changes. Rebasing _really_ should not be a lot of
> > > > > work. And you are going to have to do it sooner or later, either upfront
> > > > > or after your patches stop applying because the block changes went
> > > > > upstream.
> > > > 
> > > > The task of running the secondary tree is not merely rebasing of patches
> > > > (which I already do on a daily basis) as it also involves extra coordination,
> > > > testing, updates etc.
> > > 
> > > Coordination with whom? If people develop off your pata tree, then there
> > > should be no difference.
> > 
> > Coordination between trees.
> > 
> > Moreover people often develop against linux-next (this is perfectly
> > fine with the current development model) which after change would mean
> > that their patches could end up being dependent also on block (more
> > work for me to sort it out).
> 
> And the difference being? The block tree is in -next in the first place.
> This changeset is not yet, since I haven't had time to do testing on it
> yet. But the tested stuff is usually there for each iteration.

pata tree is based on Linus' tree _not_ on linux-next and this is very
handy when it comes to preparing pull requests.

It could be that I worry needlessly but with ~170 patches in the tree
currently, lack of time and merge window around the corner there is
no wonder that I'm reluctant to any experiments.  However I completely
agree that we should look into the ways of improving the process in
the longer-term.

Thanks,
Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/