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] Feature development model: pull request?
Date Mon, 11 Apr 2016 13:55:29 GMT
Hello.

On Mon, 11 Apr 2016 08:04:54 -0400, Rob Tompkins wrote:
> All,
>
> I was thinking about this some over the weekend. How many of the
> contributors (those without commit access to the apache repository),
> do you think, will be accessing and submitting code via GitHub pull
> request? I ask because GitHub offers a template mechanism for pull
> requests.

Impossible to say (statistics is too poor). :-}
But even for one potential contributor, it would be worth to make
the process as simple and clear as possible.

> Generally, a pull request is a request to merge a remote branch into
> a central branch. What comes along with the merge request is a title
> and message as well as an associated comment thread. GitHub currently
> accommodates for “templating” the message portion of the pull 
> request.
> It essentially provides a standardized format for the pull request
> message. Further, one can use HTML style comments in the template for
> items that we do not wish to be presented in the GitHub user 
> interface
> (directions and such that we don’t want to show up in the GitHub user
> interface). For example, the spring-boot project’s .github 
> directory's
> (https://github.com/spring-projects/spring-boot/tree/master/.github)
> pull request template has the following HTML comment:
>
> <!--
> Thanks for contributing to Spring Boot. Please provide a brief
> description of your pull-request and reference any related issue
> numbers (prefix references with #).
> -->
>
> Is there any appetite for such an item in the commons-math repo?

It seems like a good idea.  But perhaps others should comment about
any requirements.

> If
> so I can get a Jira issue started and a pull request in to master &
> develop with the changes.

Thanks, but please read
   doc/development/development.howto.txt
The template should NOT assume that the code is to be merged in either
"master" or "develop".
A contribution should be related to a JIRA report and be merged in
an ad-hoc branch before a committer will merge _that_ branch into
"develop".
Now, we can anticipate that for some "trivial" contributions (e.g. a
short documentation fix, or formatting), it would be nice to not have
to make the detour through a new branch.

So I'd propose to prepare:
* one template for trivial changes (into "develop") that do not modify
   the code,
* one template for other changes (specifically _not_ into "develop")
   that _must_ be linked to a JIRA issue.


Regards,
Gilles

> All the best,
> -Rob
>
>
>
>
>> On Apr 8, 2016, at 7:08 PM, Gilles <gilles@harfang.homelinux.org> 
>> wrote:
>>
>> On Fri, 08 Apr 2016 16:18:25 +0200, Gilles wrote:
>>> Hello.
>>>
>>> Struggling with how to share non-committer contributions:
>>>  https://issues.apache.org/jira/browse/MATH-1290
>>>
>>> At some point, we should have a paragraph in
>>>  doc/development/development.howto.txt
>>> that would explain which steps the contributor and committer must
>>> follow (i.e. one, simple, fool-proof, way) in order to, 
>>> respectively,
>>> create and merge a pull request.
>>
>> Just noticed that there is a pretty clear recipe here:
>>  https://github.com/apache/commons-math/blob/master/CONTRIBUTING.md
>>
>> Regards,
>> Gilles
>>
>>>
>>>
>>> Thanks,
>>> Gilles


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


Mime
View raw message