As someone who just went through attempting to submit my first patch I really struggled with the guide.
Personally I could really have benefitted for a ?Gerrit for Github Users? guide, to understand the differences (ie Patch vs PRs, working straight against master vs in sub-branches etc). Also the guide didn?t really cover how to update a patch after submitting it and getting a code review. I ended up creating a new patch, and luckily some nice people told me what I had to do to update a patch. To be honest it was half luck that I got that patch updated ? answers to the questions asked below would have been very helpful for us newbies. Having said that, thank you for the wiki though. Without it I never would have submitted anything ?? /Morten From: Mats Wichmann<mailto:m...@wichmann.us> Sent: Wednesday, January 11, 2017 9:59 AM To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: [dev] visiting "how to use Gerrit" topic After digging some, and watching a bunch of changes, I'm still trying to figure out what are the preferred modes of working. If the answers to these questions provide new information, I will update the wiki page https://wiki.iotivity.org/submitting_to_gerrit 1. Do developers develop fixes (as distinguished from large new features) each in a separate local branch before pushing to gerrit? Some gerrit-using projects explicitly suggest that, our wiki page is silent. 2. If you want to fix several not intimately related things in a file, is it preferred to make that look like one change or several? My "learn how this works" commit used the second method, but that looks sub-optimal to me as far as how gerrit works. To see what I'm talking about: https://gerrit.iotivity.org/gerrit/15961 https://gerrit.iotivity.org/gerrit/15963 https://gerrit.iotivity.org/gerrit/15965 I guess it comes down to what reviewers find easier? (some communities are very explicit about "make every topic a distinct patch" behavior). 3. What is the preferred way to rebase when the target has moved on? A rebase button will appear in gerrit - should it happen there, or should you rebase on your local machine? Any tips on rebasing? 4. Figuring out the right set of reviewers for a change seems daunting (there was another message on that topic recently, I believe). We do have a page of maintainers, but that page doesn't have emails, and gerrit seems to want to match the email address. This note was in IRC 6/recently: <Hauke> how do I find out who maintains which part of the code? <Hauke> the linux kernel has a nice ./scripts/get_maintainer.pl script which returns the people that a patch should be send to as well as the thought that there could be a MAINTAINERS file in the codebase itself. 5. You need to identify the person who can approve and merge your change, certainly, but will also want to identify other appropriate code reviewers. Any thoughts on how to do that beyond "just knowing"? 6. Is there a policy on whether commits require a matching Jira ticket? Mandatory? Suggested? Completely optional? 7. Is it expected that reviewers have to re-review after each new patchset in a fix? That seems kind of inefficient if you've approved the code changes, then the patch needs rebasing because of other activity but the changes in the patch were not affected. Or is it better not to try to make such distinctions and just review every time. Thanks, Mats _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170111/d7e3d780/attachment.html>
