Re: [PATCH v2 01/10] object.c: stop supporting len == -1 in type_from_string_gently()

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

>> At least, replacing an already queued topic with v2 would not
>> increase the number of topics that are supposedly in-flight but not
>> quite moving due to lack of reviews and responses, unlike bunch of
>> totally new patches ;-)
>
> I'm not sure what to do to improve things in that area.
>
> I'm obviously for increasing the net velocity of my patches making it to
> master, but if it's held up my number of reviews a submission of Y won't
> necessarily make X worse, since people who've got an interest in Y will
> be different than those with an interest in X.
>
> But some of it's definitely on my end, e.g. re-rolls sometimes taking me
> longer than I'd prefer. It's a different activity to dissect outstanding
> reviews & re-roll than writing code, and sometimes I'm interested in one
> over the other...

What I'd like to encourage contributors to think is the velocity in
the whole project, not only their own patches.  The changes proposed
on the list would consume the review bandwidth, which is
unfortunately not an infinite resource.

To balance the supply and the consumption, one way might be to
throttle incoming patches to restrict consumption and distribute the
supply more evenly among authors.  But a more desirable way that
would benefit the community more would be to increase the supply.

If all of those who consume the review bandwidth tip in by reviewing
others' patches, not limited to the area they are interested in but
more in the "I am not so familiar with the area, but I've been here
long enough and know general principles, so let's polish your patch
together" spirit, that would help the community greatly, I would
think, by:

 - replenishing review bandwidth they consumed from the pool;

 - throttling their patch flow that consume review bandwidth (while
   they are reviewing others patches, they won't be throwing new
   patches at the list to consume even more review bandwidth);

 - helping the reviewers themselves become more familiar with the
   parts of the code they are not working in right now.

I am reasonably sure I and a few others on the list are net
suppliers of the reviewer bandwidth.  I do not expect all the
prolific contributors to become net suppliers; after all, designing
and writing their own stuff is always fun.  But I wish that the most
prominent contributors in the community to be reviewing others'
topics and ushering these topics to completion from time to time,
and I am hoping to see that happen more.

Thanks.