[PATCH 01 of 11] util: put compression code next to each other

Gregory Szorc gregory.szorc at gmail.com
Wed Nov 2 17:52:52 EDT 2016


On Wed, Nov 2, 2016 at 7:26 AM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 11/02/2016 01:08 AM, Gregory Szorc wrote:
>
>> # HG changeset patch
>> # User Gregory Szorc <gregory.szorc at gmail.com>
>> # Date 1476577441 25200
>> #      Sat Oct 15 17:24:01 2016 -0700
>> # Node ID 60f180c9a030ebcee6c6f4f8584fdb94c73ac337
>> # Parent  e5cc44ea12de681d971fcbebb65a7fb71fd1c3c7
>> util: put compression code next to each other
>>
>> ctxmanager was injecting itself between the compression and
>> decompression code. Let's restore some order.
>>
>
> patch 1 is pushed, patch 2 is yet to be reviewed.
>
> Some feedback on your submition scheme, given the size of patches 2 (and
> therefor likeness of comment), it would have been better to keep the series
> small in the form of:
>
> 1) preparatory patches
> 2) large/new/complex patch
> 3) minimal usage of the new code
>
> Then you can send a larger series of more trivial usage of the new code
> once it is accepted.


>From my experience, submitting code to introduce a new API without clear
examples of how that API is used makes things harder because it isn't clear
how the new code will be used and/or why it is necessary. A reviewer could
justifiably drag their feet until these questions are answered. Code
answers those questions.

I agree that part 2 could have been split. However, I thought it best to
introduce a semi-complete snapshot of the API in a single go so reviewers
didn't have to piece it together from several diffs. Now that you've seen
the general scope of what I'm doing, if you want me to split it up, I can.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161102/6c6c875e/attachment.html>


More information about the Mercurial-devel mailing list