<html><head><META http-equiv="Content-Type" content="text/html;charset=utf-8"></head><body><div id="content" contenteditable="true" spellcheck="true" autocorrect="true" autocapitalize="true" style="font-family: Helvetica;">Would it make sense to integrate gerrit? <div><br></div><div>I love the review I'm all for it. I asked for the issue because I knew it was merged. No issues at all with comments. </div><div><br></div><div>I've work a project with gerrit and it seems that would resolve the issue with losing context<br><br>Sent from my iPhone using IBM Verse<br><br><hr>On Feb 11, 2016, 5:09:41 PM, "Andrew Jeffery" <andrew@aj.id.au> wrote:<br><div style="margin-left: 15px;" id="MaaS360PIMSDKOriginalMessageId">On Fri, 2016-02-12 at 08:15 +1100, Stewart Smith wrote:<br>> Chris Austen <austenc@us.ibm.com> writes:<br>> > Open an issue to migrate to inet_pton.<br>> <br>> Fixing such things in code review is a much better approach.<br>> <br>> For the submitter, it helps get quick feedback on tehir code, and<br>> promotes a culture of examining your own code closely for things before<br>> submitting it.<br>> <br>> For maintainers and those who hare going to have to debug the systems,<br>> it means that it's *very* quick and cheap (in time) to point out odd<br>> things.<br>> <br>> Opening issues is approximately an order of magnitude slower.<br>For transparency, I sent the email despite knowing the code had been<br>merged at the point I hit send because the timeline went along the<br>lines of: Open my laptop for the day, start reading email, come across<br>the patch, find some areas that I think we can improve on, write 90% of<br>the reply, head to github to check a small detail, discover the patch<br>has already been merged.<br>Since I'd spent some time composing the review I didn't want to throw<br>it away or spend further time to massaging it into a github issue with<br>the necessary context, so I reworded the first paragraph to reflect the<br>fact that it was already merged and hit send. This dovetails into<br>Stewart's point below, primarily the one about github issues lacking<br>the code context for the comments (without some manual effort). To be<br>fair as it stands the github issue I created doesn't (yet) contain any<br>of the context or comments provided in the email review, but at least<br>that's available through the list archives (and can be easily linked in<br>a comment).<br>Maybe this should be a separate thread, but anyway: I find the mailing<br>-list/github split a little awkward - is there a way we can improve<br>this? Use one xor the other?<br>Andrew<br>> <br>> I can hit reply, type ten words and hit send in maybe a few seconds. For<br>> an issue, you're adding a couple of seconds in network round trip to<br>> browse to the project, go to issues, click create issue, then type a<br>> whole description of the problem because you don't have the context of<br>> what you're trying to reply to, and then manage the issue by adding<br>> tags, target releases, closing it when something is finally merged (and<br>> having the submitter have to open another pull request and keep track of<br>> it)... Urgh.<br>> <br>> Good code review provides a positive feedback loop of improvement to<br>> code with a positive reinforcement at the end of "patch merged!"<br>> Contrast this to the negative re-inforcement of filing bugs, of which<br>> there is little to no direct motivation for the code author to go and fix.<br>> <br></austenc@us.ibm.com></div></div></div><BR>
</body></html>