From: Cornelia Huck <cohuck@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
Thomas Huth <thuth@redhat.com>, Alexander Graf <agraf@suse.de>,
David Hildenbrand <david@redhat.com>,
Richard Henderson <rth@twiddle.net>
Cc: qemu-s390x@nongnu.org, qemu-devel@nongnu.org
Subject: [Qemu-devel] [RFD] [s390x] Tweaking the s390x maintainership setup
Date: Fri, 24 Aug 2018 13:37:57 +0200 [thread overview]
Message-ID: <20180824133757.1cbdba75.cohuck@redhat.com> (raw)
Hi all,
while I think the current s390x maintainership setup is working quite
well, there's probably still room for improvement. In particular, I'd
like to spread out the work a bit more and make it easy to test things
pre-integration in an automated way.
As a recap, how it works today:
- We have designated maintainers for some major areas:
* tcg
* KVM
* s390 virtio-ccw machine
* s390 bios
* vfio-ccw
* virtio-ccw
- I'm acting as overall s390x maintainer, queuing patches onto my
s390-next branch (s390-fixes for fixes during freeze) and sometimes
pulling s390 bios updates (if I don't apply them myself). I'm
generally the only person that sends pull requests for master.
Some problems I've noted:
* The bus factor -- or, put in a less dramatic way, what happens when
I'm sick or on vacation? For fixes during freeze, there's no problem
if the other maintainers submit them directly, but I really don't want
to be the single point of failure (plus, I'm the only person listed
as vfio-ccw maintainer).
* The IBM folks can't do tcg.
* Conversely, the non-IBM folks cannot review things that don't have
public documentation (yet), other than in a very general way.
* I don't want to pick everything myself :) Especially when I basically
rely on other people noticing problems in the first place (like with
the non-public things or code areas I'm not so familiar with).
* Testing seems to be a bit ad hoc. It would be nice to have a branch
that (semi) automated tests can be run on before things hit upstream,
and that is also created on top of current master. (I usually only
rebase the pushed-out s390-next branch when I apply new patches, and
sometimes not even then.) Oh, and other people testing things,
especially on different hardware.
So, here are some ideas I had on how to improve things:
* Split up maintainership a bit more. For example, split out areas like
pci for which no public documentation is available; these need to
have at least one IBM maintainer. Another candidate would maybe be
the cpu model.
* On a related note, more maintainers from IBM would be nice :) For
example, for vfio-ccw, where I'm the only maintainer... Some R:
entries would not hurt, either.
* More trees to pull from. Of course, not every area needs a dedicated
tree (that would become silly pretty quickly), but for example a tcg
tree would be nice. I can still pick individual patches if a pull
request would be overkill.
* I'd also like to have a designated backup for the overall
maintainership, especially for when I'm on vacation (like the first
two weeks of September, just to let you know :) or otherwise
unavailable, but also for sanity. Likely needs to be a non-IBMer due
to the tcg problem.
* A more predictable s390-next would be nice. Maybe have it
(semi-)automatically created out of the different trees, on top of
current master? I would start to apply patches on a new branch that
feeds into s390-next rather than on s390-next directly, then.
* Do something about (semi-)consolidated, (semi-)automatic testing.
Like hooking into Travis (or something similar), sharing test setups,
and enabling tests to be run on a range of platforms (including very
recent ones). Testing is probably a large topic on its own, though.
Thoughts?
next reply other threads:[~2018-08-24 11:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-24 11:37 Cornelia Huck [this message]
2018-08-27 9:26 ` [Qemu-devel] [RFD] [s390x] Tweaking the s390x maintainership setup David Hildenbrand
2018-08-27 10:40 ` Cornelia Huck
2018-08-27 10:52 ` Thomas Huth
2018-08-27 11:33 ` Peter Maydell
2018-08-27 12:02 ` Christian Borntraeger
2018-08-27 12:37 ` Cornelia Huck
2018-08-27 12:47 ` David Hildenbrand
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=20180824133757.1cbdba75.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--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.