You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@milagro.apache.org by Simeon Aladjem <si...@miracl.com> on 2016/09/01 07:55:44 UTC
Contribution process
Hello everyone,
As I think we never stated clearly what the contribution process should be,
and as it crystalized to me in the recent month, I would like to take the
chance and propose the following process:
*Branching/Forking Strategy*
1. The most convenient way for that is to for one of the
*incubator-milagro* repositories from GitHub, i.e. from
https://github.com/apache/incubator-milagro-*****.git.
2. A branch for the specific work should then be created in the forked
repository
*Submitting Changes for Review*
1. After the changes have been complete, meeting all the code quality
requirements of the project (still TBD), a Pull Request should be done in
GitHub to merge the branch with the changes from the forked repo to the
*master* of the *incubator-milagro* GitHub repo.
2. The Pull Request will be discussed over GitHub and if necessary it
will be updated during the review process.
*Merging the Changes*
As the GitHub repos are just one-way mirroring at the moment the repos in
git://git.apache.org <git://git.apache.org/incubator-milagro-crypto.git> (
https://git1-us-west.apache.org/repos/asf), the changes cannot be merged
over GitHub. For this reason the following steps need to be taken to merge
the contribution:
1. Clone locally the respective repository from
https://git1-us-west.apache.org/repos/asf. For instance, if the
contribution is in https://github.com/apache/incubator-milagro-crypto.git,
the repo
https://git1-us-west.apache.org/repos/asf/incubator-milagro-crypto.git
should be cloned.
2. Add the repository from which the code should be merged (let’s call
it contribution repo) as an additional remote in the local repo that was
just cloned.
3. Merge the branch from the contribution repo to the master of the
Apache repo. If the contrition code is based properly, this merge should be
trivial one.
4. Commit and push the changes to the Apache repo origin. Note that
this step requires authentication, for which purpose the merging developer
should have an Apache ID with proper permissions.
Please comment on the above. I would like to raise it for voting in a short
while.
Best Regards,
*Simeon Aladjem*
*MIRACL*
Re: Contribution process
Posted by Nick Kew <ni...@apache.org>.
On Thu, 2016-09-01 at 10:55 +0300, Simeon Aladjem wrote:
> As I think we never stated clearly what the contribution process should be,
> and as it crystalized to me in the recent month, I would like to take the
> chance and propose the following process:
Your process works well for me. Thanks for spelling it out.
The github process you've described supports contributions from
anyone with a github account, regardless of whether they're
also part of the team at Apache. This is a Good Thing.
We should certainly allow, and indeed encourage, this process.
The question for the project is whether we want to enforce it,
or whether we're happy to skip the github parts of the process.
An alternative would be for the contributor to fork a branch
directly from Apache, and then submit the patch as a Jira ticket
(or in the case of a trivial update, merge it directly).
A separate question of policy is how to manage separate branches
without the intention of merging into a master. This becomes
applicable once we have a stable release that's under maintenance
but not active development.
--
Re: Contribution process
Posted by Nick Kew <ni...@apache.org>.
On Thu, 2016-09-01 at 10:00 +0100, Kealan Mccusker wrote:
> Is two-way mirroring out of the question, as it would greatly simplify the
> contribution process?
It's expected to happen, but we don't know quite when.
It's been happening experimentally for a while with a couple of
selected projects. One of those is Trafficserver, where it seems
to be running pretty smoothly.
--
Nick Kew
Re: Contribution process
Posted by Kealan Mccusker <ke...@miracl.com>.
Hi All
In the absence of a two-way mirror then this process does seems to be only
way forward.
Is two-way mirroring out of the question, as it would greatly simplify the
contribution process?
regards
Kealan
On Thu, Sep 1, 2016 at 8:55 AM, Simeon Aladjem <si...@miracl.com>
wrote:
> Hello everyone,
>
>
>
> As I think we never stated clearly what the contribution process should be,
> and as it crystalized to me in the recent month, I would like to take the
> chance and propose the following process:
>
>
>
> *Branching/Forking Strategy*
>
>
>
> 1. The most convenient way for that is to for one of the
> *incubator-milagro* repositories from GitHub, i.e. from
> https://github.com/apache/incubator-milagro-*****.git.
>
> 2. A branch for the specific work should then be created in the forked
> repository
>
>
>
> *Submitting Changes for Review*
>
>
>
> 1. After the changes have been complete, meeting all the code quality
> requirements of the project (still TBD), a Pull Request should be done in
> GitHub to merge the branch with the changes from the forked repo to the
> *master* of the *incubator-milagro* GitHub repo.
>
> 2. The Pull Request will be discussed over GitHub and if necessary it
> will be updated during the review process.
>
>
>
> *Merging the Changes*
>
>
>
> As the GitHub repos are just one-way mirroring at the moment the repos in
> git://git.apache.org <git://git.apache.org/incubator-milagro-crypto.git> (
> https://git1-us-west.apache.org/repos/asf), the changes cannot be merged
> over GitHub. For this reason the following steps need to be taken to merge
> the contribution:
>
> 1. Clone locally the respective repository from
> https://git1-us-west.apache.org/repos/asf. For instance, if the
> contribution is in https://github.com/apache/incubator-milagro-crypto.git,
> the repo
> https://git1-us-west.apache.org/repos/asf/incubator-milagro-crypto.git
> should be cloned.
>
> 2. Add the repository from which the code should be merged (let’s call
> it contribution repo) as an additional remote in the local repo that was
> just cloned.
>
> 3. Merge the branch from the contribution repo to the master of the
> Apache repo. If the contrition code is based properly, this merge should be
> trivial one.
>
> 4. Commit and push the changes to the Apache repo origin. Note that
> this step requires authentication, for which purpose the merging developer
> should have an Apache ID with proper permissions.
>
>
>
> Please comment on the above. I would like to raise it for voting in a short
> while.
>
>
>
> Best Regards,
>
>
>
> *Simeon Aladjem*
>
> *MIRACL*
>