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.ben...@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
signature.asc
Description: PGP signature
