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

[Andrew Jeffery]

On Fri, 2016-02-12 at 03:12 +0000, Chris Austen wrote:
> Would it make sense to integrate gerrit?  
> 
> 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. 
> 
> I've work a project with gerrit and it seems that would resolve the
> issue with losing context

In a past life I (haphazardly) maintained (and used) a Gerrit instance
for several years. It has its pros and cons, but probably the bigger
issue as Stewart points out would be fracturing the development process
with respect to other projects in the OpenPOWER stack (along with the
problems of hosting/sysadmin/system integration).

It's convenient to have all comments visible against a line rather than
spread over multiple reviewers' emails, but from a feature perspective
a fairly large drawback was Gerrit's handling of patch series. Up until
recently management of a series could be half-heartedly done through
'topics', but the patches still needed to be submitted individually
through the web UI or by a combination of web UI and git operations.
There was a plan to introduce a feature to atomically merge all patches
in a topic, but I haven't checked on the state of that recently.
There's also some tedium involved when patches are split or squashed,
as the older revisions can often (confusingly) hang around in the web
UI until they are manually abandoned. A simple 'v2' does away with
those problems on a mailing list or github pull-req. But maybe these
are usability issues that we can work around/cope with? Overall I don't
think Gerrit would be my choice in this context.

Using the mailing list with patchwork and snowpatch (a patchwork CI
-related tool brewing at ozlabs) might give us github-levels of CI
testing infra integration without the need for github? That would just
leave sorting out email for non-LTC IBM people...

Andrew

> 
> Sent from my iPhone using IBM Verse
> 
> On Feb 11, 2016, 5:09:41 PM, "Andrew Jeffery" <andrew at aj.id.au> wrote:
> On Fri, 2016-02-12 at 08:15 +1100, Stewart Smith wrote:
> > Chris Austen  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/20160217/3171011e/attachment.sig>