?Adding to what Morten mentioned, I have the following issue: If two developers are working on the same patch, how to allow the other developer (i.e. the one who did not originally submit the patch) to make an update from his local machine? In our case, I had to submit the patch manually to the other developer who would then push the update to gerrit. This causes unnecessary details.
I am sure there must be some way but I cannot find it as a new user of gerrit. Best regards On Wed, Jan 11, 2017 at 8:42 PM, Morten Nielsen <mn at iter.dk> wrote: > 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 <mats at wichmann.us> > *Sent: *Wednesday, January 11, 2017 9:59 AM > *To: *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 > > _______________________________________________ > 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/20170112/66e34db4/attachment.html>
