qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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?

             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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).