commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Clarification of development model with Git
Date Thu, 21 Apr 2016 13:28:29 GMT
On Thu, 21 Apr 2016 09:34:23 +0200, luc wrote:
> Le 2016-04-21 02:39, Gilles a écrit :
>> On Wed, 20 Apr 2016 18:14:33 +0100, sebb wrote:
>>> On 20 April 2016 at 02:55, Gilles <gilles@harfang.homelinux.org> 
>>> wrote:
>>>> Hello.
>>>> Let's assume the following:
>>>> * Some feature branch has been pushed to the Apache repository.
>>>> * That branch fixes an issue reported in JIRA.
>>> Has the JIRA been updated with the details of the code push?
>> Whenever code was available, I indicated it with a comment on the
>> corresponding JIRA page; and all comments generate a post to this
>> list.
>>
>>>> * Nobody has raised an objection after some time[1] has passed.
>>>> Can we conclude that the code in that branch has been (lazily)
>>>> accepted and can be merged into "develop"?[2]
>>> If you are not sure, why not send an email round asking about the
>>> specific commits?
>> Done.
>> But the question is: How long should one wait for review (in C-T⁻R
>> policy)?
>
> I think you can safely consider that the recent development
> can be integrated as you want.

Thanks for the green light.

However, reminding the fuss about the issues related to the
random number generators, I feel quite uncomfortable that nobody
has tested the new API, or if someone did, that no report (good
or bad) has reached this list or JIRA.

The questioning is thus whether git branches are considered
"commit" (as in C-T-R policy), and the subsequent assumption
that the new code has been accepted (if not "+1", then at least
"lazily"). Or if people consider that feature branches are a sort
of "sandbox", and "commit" (as in C-T-R) only happens when the
branch is merged into "develop" (at which point they will start
to look at the code and eventually issue "-1").

Personally, I think that the latter option is inefficient and
not in line with the clarity which git can promote, since we'd
have a "develop" branch that contains a lot of "reverted"
commits.
When development is advertised on this list and on JIRA (comment
saying that code is ready for review), then merging into "develop"
should be the end of the review process.[1]
I think that this must be clarified in the development guidelines.

Regards,
Gilles

[1] Bugs notwithstanding, of course.

> best regards,
> Luc
>
>> A similar situation is: When I post a message on the ML, asking
>> whether there are objections to some proposed work, how long should
>> I wait before implementing the suggested solution?
>> Example:
>>   http://markmail.org/thread/ywdfvyq6hmbaje6u
>>
>> Regards,
>> Gilles
>>
>>>> [1] What would be reasonable value for the time span?
>>>> [2] So that other issues that depend on that code can be worked
>>>>     on.
>>>>


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


Mime
View raw message