[
https://issues.apache.org/jira/browse/S4-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174896#comment-13174896
]
Patrick Hunt commented on S4-35:
--------------------------------
bq. not intended to be rigid and eternal but rather to keep improving as we
gain experience
that's an excellent point.
bq. patch reviews: do they need to be performed by committers only?
Anyone can review patches, some projects looks for both patch contributions as
well as reviews as part of granting committership. However the person who
commits the code to svn is responsible for verifying the files/changes they
commit. See this
http://www.apache.org/dev/committers.html#committer-responsibilities
"Applying patches: In order to grow and maintain healthy communities,
committers need to discuss, review and apply patches submitted by volunteers.
The Committers are also responsible for the quality and IP clearance of the
code that goes into ASF repositories."
> 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
