[PATCH phosphor-host-ipmid v2] IPMI Get IP Support

[Andrew Jeffery]

On Fri, 2016-02-12 at 08:15 +1100, Stewart Smith wrote:
> Chris Austen <austenc at us.ibm.com> writes:
> > Open an issue to migrate to inet_pton.
> 
> Fixing such things in code review is a much better approach.
> 
> For the submitter, it helps get quick feedback on tehir code, and
> promotes a culture of examining your own code closely for things before
> submitting it.
> 
> For maintainers and those who hare going to have to debug the systems,
> it means that it's *very* quick and cheap (in time) to point out odd
> things.
> 
> Opening issues is approximately an order of magnitude slower.

For transparency, I sent the email despite knowing the code had been
merged at the point I hit send because the timeline went along the
lines of: Open my laptop for the day, start reading email, come across
the patch, find some areas that I think we can improve on, write 90% of
the reply, head to github to check a small detail, discover the patch
has already been merged.

Since I'd spent some time composing the review I didn't want to throw
it away or spend further time to massaging it into a github issue with
the necessary context, so I reworded the first paragraph to reflect the
fact that it was already merged and hit send. This dovetails into
Stewart's point below, primarily the one about github issues lacking
the code context for the comments (without some manual effort). To be
fair as it stands the github issue I created doesn't (yet) contain any
of the context or comments provided in the email review, but at least
that's available through the list archives (and can be easily linked in
a comment).

Maybe this should be a separate thread, but anyway: I find the mailing
-list/github split a little awkward - is there a way we can improve
this? Use one xor the other?

Andrew

> 
> I can hit reply, type ten words and hit send in maybe a few seconds. For
> an issue, you're adding a couple of seconds in network round trip to
> browse to the project, go to issues, click create issue, then type a
> whole description of the problem because you don't have the context of
> what you're trying to reply to, and then manage the issue by adding
> tags, target releases, closing it when something is finally merged (and
> having the submitter have to open another pull request and keep track of
> it)... Urgh.
> 
> Good code review provides a positive feedback loop of improvement to
> code with a positive reinforcement at the end of "patch merged!"
> Contrast this to the negative re-inforcement of filing bugs, of which
> there is little to no direct motivation for the code author to go and fix.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160212/4053746b/attachment.sig>