incubator-s4-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karthik Kambatla (Commented) (JIRA)" <>
Subject [jira] [Commented] (S4-35) define development workflow for git
Date Tue, 13 Mar 2012 19:06:41 GMT


Karthik Kambatla commented on S4-35:

Just wanted to follow up on this issue with some feedback.

The workflow seems to be working very well, except the issue with multi-commit patches. From
what I have read online, it seems like git format-patch is the right/only way to generate
patches should we choose to preserve commit information. However, git format-patch creates
multiple files for multiple commits, which can be cumbersome. To add to that, if the patches
have issues, going back and forth and uploading multiple patch files each time leads to more

Given that we have a github account as well, what do you think of going back to the github
way of collaborating? Each JIRA can be a branch and contributors can issue pull requests.
Reviewing will also become significantly easier.
> define development workflow for git
> -----------------------------------
>                 Key: S4-35
>                 URL:
>             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
> * *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
> # 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
> # 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:!default.jspa
For more information on JIRA, see:


View raw message