All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Chad Joan <chadjoan@gmail.com>,
	qemu-trivial@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems.
Date: Fri, 17 Feb 2017 18:11:31 +0800	[thread overview]
Message-ID: <20170217101131.GA3468@lemon.lan> (raw)
In-Reply-To: <2a2570bf-2e4b-e793-4362-0a679b182b1e@redhat.com>

On Fri, 02/17 10:23, Laszlo Ersek wrote:
> On 02/17/17 07:43, Fam Zheng wrote:
> > On Thu, 02/16 12:47, Chad Joan wrote:
> >> I am glad others are chiming in and might provide better solutions.
> >>
> >> Honestly, following the instructions at
> >> http://wiki.qemu-project.org/Contribute/SubmitAPatch to-the-letter is quite
> >> daunting to me, just to get one line of code changed.  It might help if
> >> that page had some kind of dead-simple example for trivial patches;
> >> something like:
> >> $ cd <QEMU directory>
> >> $ git format-patch blah blah blah
> >> $ maybe-some-other-command
> >> $ # Now copy the contents of file xyz.patch into your email client and send
> >> to qemu-devel@nongnu.org and qemu-trivial@nongnu.org
> > 
> > Makes sense in general except for the sending part - email clients tend to
> > damage the patch when you copy and paste by wrapping long lines or messing up
> > other things. But your point is taken, we should make the first (or a one-shot)
> > contribution as easy as possible.
> 
> I disagree (from the sidelines, that is; I'm not a QEMU maintainer --
> I'm a co-maintainer elsewhere). The patch submission process exists for
> a reason, the goal is to maximize the throughput of long-term
> contributors and maintainers, because that's the best for the project's
> overall health and progress.

Having a process and smoothly revealing it to new contributors are not in
conflict. The problem here is the long SubmitAPatch I think. It does include
more details than needed for the minimum of the very first submission; also it
is not in an easy-to-follow step-by-step form.

I believe people will happily learn the process once he feels appreciation on
his effort, once they get replies to his patch. :)

> 
> It does not mean that one-off contributions are not welcome -- all
> contributions are welcome that follow the process (and beyond that,
> everyone is welcome to become a long-term contributor).

IMHO one-off _fixes_ are also good, like this one. Like Peter noted, the only
recommendation for those who don't like formalities and have no intention to
contribute regularly, is to add a "signed-off-by" line to their patch.

> 
> Just my two cents, of course; don't take this as an official standpoint
> or whatever. (And, I'm saying this after having manually fixed up
> garbled patches from one-off contributors.)
> 
> Laszlo

Fam

  reply	other threads:[~2017-02-17 10:11 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-16 16:30 [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems Chad Joan
2017-02-16 16:58 ` Paolo Bonzini
2017-02-16 17:23   ` Laszlo Ersek
2017-02-16 17:47     ` Chad Joan
2017-02-17  6:43       ` Fam Zheng
2017-02-17  9:23         ` Laszlo Ersek
2017-02-17 10:11           ` Fam Zheng [this message]
2017-02-17  9:28         ` Peter Maydell
2017-02-17 15:34           ` Eric Blake
2017-02-17 16:54             ` Chad Joan
2017-02-17 16:56               ` Peter Maydell
2017-02-17 16:57               ` Paolo Bonzini
2017-02-17 17:07                 ` Chad Joan
2017-02-17 17:15               ` Peter Maydell
2017-02-19  7:22                 ` Chad Joan
2017-02-19 12:12                   ` Peter Maydell
2017-02-21  2:53                 ` Eric Blake
2017-02-17 17:17               ` Eric Blake
2017-02-19  7:02                 ` Chad Joan
2017-02-21  3:02                   ` Eric Blake
2017-02-21  9:41                     ` Markus Armbruster
2017-02-21  9:58                       ` Peter Maydell
2017-02-17 18:13             ` John Snow
2017-02-17  8:45     ` Paolo Bonzini
2017-02-17  8:56     ` Paolo Bonzini
2017-02-17  9:17       ` Laszlo Ersek
2017-02-17 11:11         ` Paolo Bonzini
2017-02-17 11:43           ` Chad Joan
2017-02-17 10:18       ` Peter Maydell
2017-02-17 11:20         ` Paolo Bonzini
2017-02-17 16:57           ` Peter Maydell
2017-04-06 18:15             ` Rainer Müller
2017-04-06 18:36               ` Peter Maydell
2017-06-02 13:58                 ` Peter Maydell
2017-02-16 16:59 ` Eric Blake
2017-02-16 17:05 ` Peter Maydell

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=20170217101131.GA3468@lemon.lan \
    --to=famz@redhat.com \
    --cc=chadjoan@gmail.com \
    --cc=lersek@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.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.