Re: [qemu-s390x] [RFD] [s390x] Tweaking the s390x maintainership setup

[David Hildenbrand]

On 24.08.2018 13:37, Cornelia Huck wrote:
> 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.

I could take care of the latter. But it usually goes hand in hand with
KVM changes (or core s390x changes for migration), so I am not sure if
splitting the cpu model out makes that much sense after all. To me, it
somehow feels "s390x core".

> * 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 can take care of that for TCG (including picking + sending pull requests).

> * 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.

Either Thomas or I could do that. I will be on vacation the first two
weeks of September, too ;) Thomas, interested?

> * 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.

Is there any fancy mechanism out there with which we can easily build
something like that (automatic merging like e.g. linux-next does)?

> * 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.

Sounds interesting to me. Especially building all different kinds of
combinations + e.g. running kvm-unit-tests / booting a simple distro.

> 
> Thoughts?
> 


-- 

Thanks,

David / dhildenb