"W. Trevor King" <wking@xxxxxxxxxx> writes:
> I just read through the manual cover to cover, so I have a number of
> other fixes in the pipe (from which I've already submitted the
> receive.denyCurrentBranch patch).
Wonderful.
> ... Should I bundle them all into a
> single series to reduce clutter on the list,...
I do think it makes much difference between a single series that
consists of 47 separate patches and a flood of 47 unrelated patches.
As long as it is not a single patch with 200 hunks, some of which
has to be redone repeatedly, I think it is fine either way.
Many of them may be a no-brainer to accept on the first try, while
some may have to be improved with the input from the list and will
be rerolled. I would imagine the initial round would be:
[PATCH v1 00/47] User manual updates
[PATCH v1 01/47] user-manual: update description of 'xyzzy'
[PATCH v1 02/47] user-manual: update description of 'frotz'
...
[PATCH v1 47/47] user-manual: update description of 'nitfol'
and after reviewing, some of them need to be redone in v2; the cover
letter for v2 would say something like
[PATCH v2 00/52] User manual updates
The patches 01-17, 19, 22-36, 39, 42-47 are the same as in
v1; 48-52 are new.
And people who missed the v1 review cycle may have a chance to look
at and respond to [PATCH v2 06/52] which may result in an update of
that patch to address issues that reviewers of the initial round may
have missed.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html