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
