Fixing std.zip

[H. S. Teoh]

On Wed, Sep 25, 2019 at 05:02:02PM +0000, berni via Digitalmars-d wrote:
> I'd like to take care of issue #20027 (and issue #20239), concerning
> std.zip. As this are actually lot's of small issues I'm not sure, how
> to handle this:
> 
> a) One big PR with lot's of small commits?
> b) One small PR after another?
> c) Like b) but trying to submit some nonclashing PRs in parallel? (not
> sure if this is possible at all)
> d) ???
> 
> What's best?

I haven't contributed a PR for a while now, but based on past
experience, my advice is to go with (b) or (c).

I recommend against (a) because, based on my past experience as PR
reviewer, large PRs tend to be:

1) Too big to review in one sitting, and so reviewers are more liable to
put off reviewing it.

2) Too big to fully comprehend without some major dedicated effort at
understanding the affected code, and since reviewers are volunteers,
this is a big disincentive to review it (I can spare 5-10 mins here or
there, but the prospect of taking 2 hours off my day job just to review
a PR is not very attractive, to say the least).

3) Easily stuck for a long time over one or two points of controversy
while the rest of the uncontroversial changes remain languishing in the
PR queue instead of being merged. Breaking your change into smaller,
more-or-less independent chunks makes it more likely that
non-controversial changes will get merged to the benefit of all, even
while some of the other changes are stuck due to discussion, etc..

4) Hard to keep up-to-date as the master branch continues to change and
merge conflicts arise. Big PRs tend to have more conflicts over time,
and the amount of effort required to resolve these conflicts on an
ongoing basis while the PR languishes in the queue can be very
off-putting. It can easily add up to more effort than writing the PR in
the first place, and not many people can stomach that.

So, don't do (a). Go with (b) or (c).


T

-- 
May you live all the days of your life. -- Jonathan Swift