Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 29 Sep 2016 02:42:30 +0200
From: Gilles <gilles@harfang.homelinux.org>
To: <dev@commons.apache.org>
Subject: [RNG] Team =?UTF-8?Q?work=3F=20=28Was=3A=20=2E=2E=2E=20commit=3A?=
 =?UTF-8?Q?=20foreach=20loops=29?=
In-Reply-To: <7fb2290d-22d7-cc5b-664d-edab48287ab6@apache.org>
References: <2bbf1b3f76574e7685ad16f3989097c4@git.apache.org>
 <bad21f4925d9497a86b51796dfca1d1f@git.apache.org>
 <9cd34dd2038797d1a6565683b155f08b@scarlet.be>
 <7fb2290d-22d7-cc5b-664d-edab48287ab6@apache.org>
Message-ID: <3c47f72e66978e484b87c3df69e8e458@scarlet.be>
User-Agent: Scarlet Webmail
X-DCC-scarlet.be-Metrics: eir; whitelist
X-Virus-Scanned: clamav-milter 0.98.1-exp at eir
X-Virus-Status: Clean
archived-at: Thu, 29 Sep 2016 00:42:48 -0000

On Thu, 29 Sep 2016 01:37:02 +0200, Emmanuel Bourg wrote:
> Le 28/09/2016 à 17:41, Gilles a écrit :
>
>> The array indexing was left on purpose (for debugging).
>> Please revert.
>
> Well, that wasn't really explicit, I'd suggest putting a comment the
> next time to materialize your intents.

Sorry but shouldn't it be the other way around, i.e. materialize
your intent to change something that looks odd to you?
Of course "foreach" is nicer; I had made that change, and reverted
it when I found myself counting the numbers on the screen...

> I made another modification to the tests and the index is now 
> reported
> when an assertion fails. Is this better?

Yes; that one is a really nice improvement in uniformity and
clarity. Thanks.

>> In general, could you please stop these unilateral changes?
>>
>> Some are going to turn out fine, some are not.
>>
>> Most are not trivial to figure out, even if they may look so
>> to you.
>
> Gilles, please relax and trust the other members here. It's great 
> that
> you review all commits but requiring your permission before 
> committing
> anything is excessive.

It's not about (my) permission; it's about caring for others'
work.
Allow them the possibility to avoid wasting time on reviewing
something that was agreed on.
It's just one post, or a JIRA report with a TODO list (as I
did in RNG-6) where one can have a quick view of what is coming,
and let it pass if obviously trivial, or ask for clarification
if not.

Overall, can you consider that my time is not worth less than
yours, and that it takes unnecessary effort to review unexpected
commits?

I'm curious of how people would have reacted if I had started
such a massive amount of cosmetic changes in other components.

I find it strange that you ask me to trust other developers
(which I do anyways, too much surely[1]) when they do not
return the favour.
I'll relax when I don't have to fight "rear guard" battles
such as about the scope of Commons RNG, or about the JDK's
"Random" being considered the eighth wonder of the world.

Will _you_ trust me on these, at least until you have more
arguments than I brought forward?

> Arguing all the day for minor changes is
> exhausting and counter-productive.

You can think that I'm stupid (for not having the same
definition of "trivial"), but do not assume that I take
pleasure in reviewing diffs (especially if they were
unannounced and uncalled for) and in writing posts,
begging for an explanation.

I proposed to delay the release because you wished to
include additional implementations.
I certainly did not expect that you'd take that opportunity
to start a beautifying crusade. [Rows of 4 numbers instead
of 5 ???]

>> Right now, I've been drowned by cosmetic changes that could hide
>> more substantial ones.
>
> Good news I think I'm done with the cosmetic changes. I'll start 
> working
> on the non trivial stuff now, on a feature branch of course.

Good news indeed.

I look forward to working as a team; please let me know
when we enter that stage. :-}


Gilles

[1] See where it got me to trust the former CM team!

>
> Emmanuel Bourg
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org