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

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

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.

Junio C Hamano wrote:

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.

The problem is that the suppliers are a club who often agree on what
code is not ready to be merged, which is most of it, and also agree it's
better to apply the reject hammer.

This club is by definition small.

There's a spectrum of perfectness, and the suppliers are on the far left
side: code has to be perfect, while most of the consumers are on the
right side, or even on the sensible middle side: do not let the perfect
be the enemy of the good.

For the suppliers club good is usually not good enough.

I'm fairly confident most of the consumers would agree the bar on what
constitutes "good enough" is too damn high, so why would they spend time
raising it any higher? They won't.

If anything they are more often going to dissagree with the suppliers
club, in order to increase the likelihood of perfectly good patches to
be merged.

As long as you keep insisting on making the perfect being the enemy of
the good, you are going to ensure the supply is *always* going to be
low.

Cheers.

-- 
Felipe Contreras