incubator-s4-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Morel (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (S4-35) define development workflow for git
Date Thu, 22 Dec 2011 15:41:30 GMT

    [ https://issues.apache.org/jira/browse/S4-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174848#comment-13174848
] 

Matthieu Morel commented on S4-35:
----------------------------------

Thanks for the comments!

I took them into account for a new version of the proposal (which by the way, is not intended
to be rigid and eternal but rather to keep improving as we gain experience).

I also added some open questions at the end.
----

We'll get a git repository hosted at Apache soon, therefore we should define a development
process that is compatible with the Apache way and takes advantage of git.


Here is a proposal, please feel free to amend/improve/reject it.

It is inspired by the linux kernel approach, where the "benevolent dictator" is actually the
S4 community, (though only committers have with write access to the blessed repository), and
where contributors submit patches from their feature branches, created after rebasing on top
of the latest changes from the blessed repository.




h3. Infrastructure:

* Apache S4 git repository is the "blessed" repository. 

* Only S4 committers have write access.

* Apache S4 git repository can be cloned by anyone, therefore anyone can contribute



h3. Repository structure:

we could adapt a suggestion from there http://nvie.com/posts/a-successful-git-branching-model/

* *master* branch holds the released code and a tag is associated to each release

* *dev* branch holds the code that has been accepted for inclusion and that will be part of
the next release



h3. Workflow:

# You may participate to the technical discussions and submit patches, without preconditions,
hence becoming a _contributor_ (see http://www.apache.org/foundation/how-it-works.html#users
)
# Whenever you make some changes to the codebase, it's good to have a related issue filed
in the issue tracker of the project and to use a similarly named branch in your Git repository.
For example, to create a branch for an issue with the key S4-42 (see http://www.apache.org/dev/git.html#workflow)
#* you can share your code during the development of the feature by pushing it to your public
repository (not sure where that will be though). For instance, you may clone the github mirror
of the Apache S4 repo, create an S4-42 branch, and share it.
#* it is easier to read commits if they start by the jira issue number that they are tackling
(e.g. "S4-42 a description")
# once the feature looks ready, you rebase on top of the changes from *dev* , generate a patch
(named by the jira number, e.g. S4-42.patch) and upload it to the corresponding Jira issue.
(use "git format-patch")
#* you also need to grant authorship to the ASF during this operation
# people review the patch (who? not sure whether they have to be committers)
#* at the moment, there is no defined process but it will be wise to settle on a review board
for complex contributions
# and vote on it (see decision making http://www.apache.org/foundation/how-it-works.html)
# when the patch is accepted, a _committer_ commits the patch to the Apache S4 git repository
(to the "dev" branch) (git am)
#* in order to clearly identify commits for a feature in the git history, we may want to use
the following strategy (indeed, I'm not sure we can keep branch information in git patches):

#*# create a local temporary branch named by the id of the jira
#*# apply the patch on it
#*# merge to the dev branch _without_ fast forward
#*# delete the local temporary branch
#*# commit
#*# push to dev
# mark the jira issue as _resolved_, and add a reference to the commit id (SHA-1) in the resolution
# if you work on a different feature, you simply fetch and merge the updates to "dev".

h3. Open questions:

* many projects in Apache seem to require at least 1 upvote before integrating a patch, even
if this patch is trivial and provided by a committer. Should we follow that strictly or be
more flexible for trivial changes (i.e. a committer could upload a patch file, then directly
+1 it and integrate it to the codebase)?
* patch reviews: do they need to be performed by committers only?
* patch review tool: we'll need to select one and set it up

                
> define development workflow for git
> -----------------------------------
>
>                 Key: S4-35
>                 URL: https://issues.apache.org/jira/browse/S4-35
>             Project: Apache S4
>          Issue Type: Task
>            Reporter: Matthieu Morel
>
> We just got accepted to the ASF git program!
> We'll get a git repository hosted at Apache soon, therefore we should define a development
process that is compatible with the Apache way and takes advantage of git.
> Here is a proposal, please feel free to amend/improve/reject it.
> It is inspired by the linux kernel approach, where the "benevolent dictator" is actually
the S4 community, (though only committers have with write access to the blessed repository),
and where contributors submit patches from their feature branches, created after rebasing
on top of the latest changes from the blessed repository.
> h3. Infrastructure:
> * Apache S4 git repository is the "blessed" repository. 
> * Only S4 committers have write access.
> * Apache S4 git repository can be cloned by anyone, therefore anyone can contribute
> h3. Repository structure:
> we could adapt a suggestion from there http://nvie.com/posts/a-successful-git-branching-model/
> * *master* branch holds the released code and a tag is associated to each release
> * *dev* branch holds the code that has been accepted for inclusion and that will be part
of the next release
> h3. Workflow:
> # Whenever you make some changes to the codebase, it's good to have a related issue filed
in the issue tracker of the project and to use a similarly named branch in your Git repository.
For example, to create a branch for an issue with the key S4-42 (see http://www.apache.org/dev/git.html#workflow)
> # you can share your code during the development of the feature by pushing it to their
public repository (not sure where that will be though). For instance, one may take the github
mirror of the Apache S4 repo, create an S4-42 branch, and share it. 
> # once the feature looks ready, you rebase on top of the changes from *dev* , generate
a patch and upload it to the corresponding Jira issue. (git format-patch)
> # people review the patch and vote on it (see decision making http://www.apache.org/foundation/how-it-works.html)
> # when the patch is accepted, a committer commits the patch to the Apache S4 git repository
(to the "dev" branch) (git am)
> # if you work on a different feature, you simply fetch and merge the updates to "dev".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message