Roman, thanks for laying out these steps! Comments below… > On May 9, 2015, at 1:29 PM, Roman Shaposhnik <[email protected]> wrote: > > Hi! > > I've just submitted GEODE-19 according to the > process we seem to have agreed to in the DICUSS > thread. Here I would like to take a moment and outline > the steps I went through. If we like them I can document > (and perhaps even automate) them. > > 1. I created the JIRA with the title and description taken > from the original pull request > > 2. I linked the original pull request via More > Link JIRA > functionality > > 3. I then downloaded the original patch correspondit > to the pull request from: > https://github.com/apache/incubator-geode/pull/1.patch > and git am applied it to my repo. Note that this way all > the original author and commit data is preserved. >
Seems like we should automate the above steps. > 4. I had to modify the patch slightly. Note that this step > could be optional -- I could've provided that feedback > to Mark and asked him to update the pull request accordingly. > IMO it’s easier to discuss changes in context. Using either reviewboard or GH for this is really helpful. > 5. Once I was satisfied with the result I squashed all > the commits into a single one corresponding to a JIRA. > I am going to strongly advocate one JIRA -- one commit > rule in most of the cases. > This makes sense in most cases. (Let’s avoid bringing feature branches into the discussion for now) > 6. I merged all the comments from all the commits, but also > made sure that the first line of the commit message follows > the standard of: JIRA-ID. Jira tittle (closes #PR) > GEODE-19. Support for creating Maven distribution (closes #1) > This is very important to be able to build CHANGES.txt > file and also close the PRs automatically. The rest of the commit > message is free form. > Yes. Read more about git commit messages practices in posts like this: http://chris.beams.io/posts/git-commit/ <http://chris.beams.io/posts/git-commit/> > 7. I created a patch via git format-patch and attached it to JIRA > asking for review. Once again -- attaching patches in git format-patch > format is really important since it lets committers preserve > the authorship information intact when comminting on other > contributors behalf. In general I’d like to see a single view of the evolution of a patch. Review board does this nicely as does a PR. Once a reviewer gives a thumbs on the change are you suggesting that the final patch get attached to the JIRA? I’d rather see a commit hash to link the actual change to the ticket. The review comments would be archived in reviewboard or on the dev list for GH right? > > 8. Once I get the required +1 I'm going to push to the master > branch. That will close the PR #1 automagically (because my > commit message has closes #1 test in it) but I will still have > to close the JIRA manually once I see that fix made it. > Is there auto-magik integration for JIRA as well? Such as described in https://confluence.atlassian.com/display/JIRACLOUD/Processing+JIRA+issues+with+commit+messages <https://confluence.atlassian.com/display/JIRACLOUD/Processing+JIRA+issues+with+commit+messages> > Thanks, > Roman. Anthony
