All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ján Tomko" <jtomko@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: pbonzini@redhat.com, thuth@redhat.com, qemu-devel@nongnu.org
Subject: Re: [RFC PATCH] blog post: how to get your new feature up-streamed
Date: Fri, 10 Dec 2021 11:51:05 +0100	[thread overview]
Message-ID: <YbMxGUTa6uqU3ydt@fedora> (raw)
In-Reply-To: <20211126203319.3298089-1-alex.bennee@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]

On a Friday in 2021, Alex Bennée wrote:
>Experience has shown that getting new functionality up-streamed can be
>a somewhat painful process. Lets see if we can collect some of our
>community knowledge into a blog post describing some best practices
>for getting code accepted.
>
>[AJB: obviously RFC for now, need material for the end]
>
>Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>---
> ...26-so-you-want-to-add-something-to-qemu.md | 100 ++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 _posts/2021-11-26-so-you-want-to-add-something-to-qemu.md
>
>diff --git a/_posts/2021-11-26-so-you-want-to-add-something-to-qemu.md b/_posts/2021-11-26-so-you-want-to-add-something-to-qemu.md
>new file mode 100644
>index 0000000..d38c0ca
>--- /dev/null
>+++ b/_posts/2021-11-26-so-you-want-to-add-something-to-qemu.md

[..]

>+The maintainers path
>+====================
>+

[..]

>+I won't pretend there isn't some commitment required when becoming a
>+maintainer. However if you were motivated enough to write the code for
>+a new feature you should be up to keeping it running smoothly in the
>+upstream. The level of effort required is also proportional to the
>+popularity of the feature - there is a world of difference between
>+maintaining an individual device and a core subsystem. If the feature
>+

Unfinished sentence.

>+Practically you will probably want to get yourself a
>+[GitLab](https://gitlab.com/qemu-project/qemu/-/blob/master/MAINTAINERS)
>+account so you can run the CI tests on your pull requests. While
>+membership of `qemu-devel` is recommended no one is expecting you to
>+read every message sent to it as long as you look at those where you
>+are explicitly Cc'd.
>+
>+Now if you are convinced to become a maintainer for your new feature
>+lets discuss how you can improve the chances of getting it merged.
>+

* let's

Jano

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2021-12-10 10:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-26 20:33 [RFC PATCH] blog post: how to get your new feature up-streamed Alex Bennée
2021-12-10 10:51 ` Ján Tomko [this message]

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=YbMxGUTa6uqU3ydt@fedora \
    --to=jtomko@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /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.