Re: bzr commit into mysql-6.0-backup branch (charles.bell:2889) Bug#44787

[Ingo Strüwing]

Hi Chuck,

Charles Bell, 06.11.2009 20:48:

> Ingo,
> 
> Thanks for the commentary. Would you suggest that having one large patch
> would have been easier to handle logistically?


Yes, if the question is about easier handling, then I'd prefer one large
patch in this case. Splitting large patches has advantages only if they
are really independent. That is, if each patch can be applied
independently from the other patches on a freshly branched team tree and
builds and tests without problems.

However, the main intention for splitting was speed, if I understand
correctly. So that implementor and reviewers can work in parallel.

>   Or do you think we should
> always process patches in serial to avoid confusion?


And then, yes, I propose to always process patches in serial to avoid
confusion. At least I as a reviewer do not want to see a new commit for
a patch, I'm in the middle of reviewing. A safe way would be to recommit
only after both reviewers commented on a patch. Or, if one finished and
the other is known not to have started yet, and is informed in time that
 he will directly start on the new version.

Even worse is recommitting the next part for changes requested for the
former part. That could be a good thing, but only if both reviewers have
not started on it yet.

> 
> I am just trying to come to an understanding of how I as a developer can
> help avoid problems in the future. ;)


If we continue the uncontrolled flow of work, we might still be slightly
faster with your work (than with one large patch), but due to the
increased effort on my side, I do definitely fall behind with my work.

> 
>>> http://lists.mysql.com/commits/89594
>>
>> What a mess. I thought, our workflow was like this:
>>
>>   Implementor               Reviewers
>>
>>   Prepare patch 1
>>
>>   Prepare patch 2           Review patch 1
>>
>>   Prepare patch 3           Review patch 2
>>
>>   Rework patch 1            Review patch 3
>>
>>   Rework patch 2            Review new patch 1
>>
>>   ...
>>
>> But when you rework a patch immediately after *one* reviewer provides
>> comments and blame the other one to use an old patch, we're not doing as
>> well as we could.
>>
>> When you publish a new list of patches every day, but reviewers need 1.5
>> to 2 days for a review of all three, we're doing a mess, but we're not
>> doing as well as we could.
>>
>> In many cases, where congestion is an issue, the motto is "Go slower to
>> move faster."
> 
> Chuck
> 


Regards
Ingo
-- 
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder,   Wolfgang Engels,   Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring   HRB München 161028