All of lore.kernel.org
 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 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.