qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] Add Markus Armbrusters code for Broadcom Per


From: Eric Blake
Subject: Re: [Qemu-arm] [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.
Date: Wed, 17 May 2017 20:52:29 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0

On 05/17/2017 01:09 PM, John Bradley via Qemu-devel wrote:
> Also available at 
> 
> https://www.dropbox.com/s/gwuquw0kirstw7a/0001-Add-Markus-Armbrusters-code-for-Broadcom-Perhiperals.patch?dl=0
> 
> Following suggestions split my original patch up. This the largest monolithic 
> chunk is 
> additional BCM device support from Markus Armbruster.
> 
> 
>>From 0b39a04030d5a2cea4fcd2159d365580ca155b78 Mon Sep 17 00:00:00 2001
> From: John Bradley <address@hidden>
> Date: Wed, 17 May 2017 18:57:21 +0100
> Subject: [PATCH] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.
> 
> Signed-off-by: John Bradley <address@hidden>
> ---

After a break from the keyboard (always a good idea), I've re-read my
comments on this thread so far.  As usual, email is a lousy medium for
conveying emotion and intent, and I can see how my curt replies merely
pointing out ways that you can improve your patch can easily be
misconstrued as negative advice or rejection of the idea in general.  So
let me take this time to apologize if I've come across as over-harsh,
and give you a big thanks for your efforts to contribute; your additions
have the potential to make qemu better.  I hope that we do not scare you
off with advice on improving your contributions up to community
standard, but that you feel welcome to contribute to the community, as
well as using the give-and-take iteration of review to make your first
patch great.  Writing a first patch series can be especially daunting
when you are new to an unfamiliar process, and while we were all once at
your point, it takes effort to remember that not everyone is as familiar
with open source ways, and how it felt on our own first patch submission.

A big hint: the great way to get a patch accepted on ANY project is to
first offer reviews on other patches being submitted to the list.
Review backlog is always present, but it gets especially bad if there
are more contributors than reviewers.  Plus, reviewing code that other
people write can give you a feel for what constitutes a typical patch
for the project, which will let you model your own submissions in the
same style.

Good luck!

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]