[Qemu-devel] [RFD] [s390x] Tweaking the s390x maintainership setup

[Qemu-devel] [RFD] [s390x] Tweaking the s390x maintainership setup

[Cornelia Huck]

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?

Re: [Qemu-devel] [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

Re: [Qemu-devel] [RFD] [s390x] Tweaking the s390x maintainership setup

[Cornelia Huck]

On Mon, 27 Aug 2018 11:26:21 +0200
David Hildenbrand <david@redhat.com> wrote:

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

I'll defer to your judgment here :)

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

Cool, thank you. I'll do a pull request before my vacation with the
current model, so we could switch after that.

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

Maybe both of you? I doubt we'll be on vacation during the same time
period every time ;)

> 
> > * 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)?

I can dig around whether there are some published scripts for that.
What we probably need is:

- a list of branches to merge
- a script that tries to merge them one by one and then pushes the
  result out

We'll probably be able to semi-automate this, but I doubt that it is
possible to do that fully automatically (conflict resolution etc.)
AFAIK, linux-next is also done semi-automatically (but also on a way
different scale :)

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

Yes, something like that. Especially on different hardware.

Re: [Qemu-devel] [RFD] [s390x] Tweaking the s390x maintainership setup

[Thomas Huth]

On 2018-08-27 12:40, Cornelia Huck wrote:
> On Mon, 27 Aug 2018 11:26:21 +0200
> David Hildenbrand <david@redhat.com> wrote:
> 
>> On 24.08.2018 13:37, Cornelia Huck wrote:
[...]
>>> * 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?
> 
> Maybe both of you? I doubt we'll be on vacation during the same time
> period every time ;)

Hmm, we already have Christian for the non-TCG stuff, and Richard is
listed in MAINTAINERs in the S390 TCG section. So I think we should
already be fine to cover you during your holidays for all areas,
shouldn't we?

Anyway, sure, I can also keep my eyes on the incoming patches during the
two weeks.

 Thomas

Re: [Qemu-devel] [RFD] [s390x] Tweaking the s390x maintainership setup

[Peter Maydell]

On 27 August 2018 at 11:40, Cornelia Huck <cohuck@redhat.com> wrote:
> On Mon, 27 Aug 2018 11:26:21 +0200
> David Hildenbrand <david@redhat.com> wrote:
>
>> On 24.08.2018 13:37, Cornelia Huck wrote:
>> > * 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?
>
> Maybe both of you? I doubt we'll be on vacation during the same time
> period every time ;)

Given that I'm also going to be on holiday, there will
not be anybody applying pullrequests, so it's a bit moot :-)

thanks
-- PMM

Re: [Qemu-devel] [RFD] [s390x] Tweaking the s390x maintainership setup

[Christian Borntraeger]

On 08/24/2018 01:37 PM, 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.
> * 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.

Yes, we (IBM) should take care of vfio-ccw (and probably also pci and ap)
Give me some more days to sort things out a bit. 

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

Is the current setup with Richard (TCG) and myself (KVM) not good enough?


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

Re: [Qemu-devel] [RFD] [s390x] Tweaking the s390x maintainership setup

[Cornelia Huck]

On Mon, 27 Aug 2018 14:02:49 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> On 08/24/2018 01:37 PM, Cornelia Huck wrote:

> > 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.  
> 
> Yes, we (IBM) should take care of vfio-ccw (and probably also pci and ap)

Just to note: I'm happy to continue taking care of vfio-ccw (especially
as I also have some code changes for it under development), but it
would be great if someone would join me. The others (pci and the
upcoming ap) should be handled by IBM, agreed.

> Give me some more days to sort things out a bit. 

Thanks for looking into this. No hurry, I'm out on vacation soon
anyway :)

> 
> > * 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.  
> 
> Is the current setup with Richard (TCG) and myself (KVM) not good enough?

It's mostly "I'm uncomfortable that it's only me". Having the tcg
maintainers resp. you handle things is absolutely fine for the usual
run of things. The only time where there might be problems is if e.g.
tcg and kvm changes interact in a non-trivial way, but I expect these
to be very rare.

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

Re: [Qemu-devel] [RFD] [s390x] Tweaking the s390x maintainership setup

[David Hildenbrand]

>>
>>> * 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.  
>>
>> Is the current setup with Richard (TCG) and myself (KVM) not good enough?
> 
> It's mostly "I'm uncomfortable that it's only me". Having the tcg
> maintainers resp. you handle things is absolutely fine for the usual
> run of things. The only time where there might be problems is if e.g.
> tcg and kvm changes interact in a non-trivial way, but I expect these
> to be very rare.

I wonder what kind of persons do things like that ;)

But yes, it should be rare and usually can wait in case you are on vacation.

-- 

Thanks,

David / dhildenb