A quick question related to the workflow. (Might not apply to the ticket, hence posting on the dev-list)
Case: I submit a patch for S4-33 , and need to use that code to address S4-36. Flow: Create a branch for S4-36 off of S4-33. At some point, either my patch or someone else's patch to S4-33 will be committed (hopefully). Rebase S4-36 at that point over dev and submit patch for S4-36 once done. Is this flow safe or can it lead to unwarranted issues because of the rebasing post commit? Thanks Karthik On Thu, Dec 22, 2011 at 12:03 PM, Patrick Hunt (Commented) (JIRA) < [email protected]> wrote: > > [ > 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 > > >
