From: Stewart Smith <stewart@linux.vnet.ibm.com>
To: Chris Austen <austenc@us.ibm.com>
Cc: andrew@aj.id.au, openbmc-patches@stwcx.xyz, openbmc@lists.ozlabs.org
Subject: Re: [PATCH phosphor-host-ipmid v2] IPMI Get IP Support
Date: Fri, 12 Feb 2016 08:15:28 +1100 [thread overview]
Message-ID: <87vb5vne33.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <201602110544.u1B5ilIu004589@d03av01.boulder.ibm.com>
Chris Austen <austenc@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.
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.
--
Stewart Smith
OPAL Architect, IBM.
next prev parent reply other threads:[~2016-02-11 21:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-10 21:40 [PATCH phosphor-host-ipmid v2] IPMI Get IP Support OpenBMC Patches
2016-02-10 21:40 ` OpenBMC Patches
2016-02-11 1:04 ` Andrew Jeffery
2016-02-11 5:36 ` Stewart Smith
2016-02-11 5:44 ` Chris Austen
[not found] ` <201602110544.u1B5il3T028608@d01av04.pok.ibm.com>
2016-02-11 6:26 ` Andrew Jeffery
[not found] ` <201602110544.u1B5ilIu004589@d03av01.boulder.ibm.com>
2016-02-11 21:15 ` Stewart Smith [this message]
2016-02-11 23:09 ` Andrew Jeffery
2016-02-12 3:12 ` Chris Austen
2016-02-12 3:28 ` Jeremy Kerr
2016-02-16 7:35 ` Stewart Smith
[not found] <201602120312.u1C3CHwh000341@d01av01.pok.ibm.com>
2016-02-16 7:33 ` Stewart Smith
[not found] <201602120308.u1C38vNo004937@d01av05.pok.ibm.com>
2016-02-16 23:45 ` Andrew Jeffery
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vb5vne33.fsf@linux.vnet.ibm.com \
--to=stewart@linux.vnet.ibm.com \
--cc=andrew@aj.id.au \
--cc=austenc@us.ibm.com \
--cc=openbmc-patches@stwcx.xyz \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.