[Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Lars Kurth]

Hi all,
    
Please propose topics by either editing the running agenda document at https://cryptpad.fr/pad/#/2/pad/edit/V-JctV2vBlEnwliVLBlFLY7n/ or by replying to the mail.

Note that currently I have
* Nothing under: 
   D) New Series / Series that need attention / Series that are important
* A prep item for the developer summit proposed by Jan at the last meeting
I also made some progress on the code of conduct topic and am about to send a mail to xen-devel@

Best Regards
Lars
    
    == Dial-in Information ==
    
     ## Meeting time
     15:00 - 16:00 UTC
     Further International meeting times: 
     https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=6&day=27&hour=15&min=0&sec=0&p1=225&p2=224&p3=24&p4=179&p5=136&p6=37&p7=33
    
     ## Dial in details
     Web: https://www.gotomeet.me/larskurth
    
     You can also dial in using your phone.
     Access Code: 906-886-965
    
     China (Toll Free): 4008 811084
     Germany: +49 692 5736 7317
     Poland (Toll Free): 00 800 1124759
     United Kingdom: +44 330 221 0088
     United States: +1 (571) 317-3129
    
     More phone numbers
     Australia: +61 2 9087 3604
     Austria: +43 7 2081 5427
     Argentina (Toll Free): 0 800 444 3375
     Bahrain (Toll Free): 800 81 111
     Belarus (Toll Free): 8 820 0011 0400
     Belgium: +32 28 93 7018
     Brazil (Toll Free): 0 800 047 4906
     Bulgaria (Toll Free): 00800 120 4417
     Canada: +1 (647) 497-9391
     Chile (Toll Free): 800 395 150
     Colombia (Toll Free): 01 800 518 4483
      Czech Republic (Toll Free): 800 500448
     Denmark: +45 32 72 03 82
     Finland: +358 923 17 0568
     France: +33 170 950 594
     Greece (Toll Free): 00 800 4414 3838
     Hong Kong (Toll Free): 30713169
     Hungary (Toll Free): (06) 80 986 255
     Iceland (Toll Free): 800 7204
     India (Toll Free): 18002669272
     Indonesia (Toll Free): 007 803 020 5375
     Ireland: +353 15 360 728
     Israel (Toll Free): 1 809 454 830
     Italy: +39 0 247 92 13 01
     Japan (Toll Free): 0 120 663 800
     Korea, Republic of (Toll Free): 00798 14 207 4914
     Luxembourg (Toll Free): 800 85158
     Malaysia (Toll Free): 1 800 81 6854
     Mexico (Toll Free): 01 800 522 1133
     Netherlands: +31 207 941 377
     New Zealand: +64 9 280 6302
     Norway: +47 21 93 37 51
     Panama (Toll Free): 00 800 226 7928
     Peru (Toll Free): 0 800 77023
     Philippines (Toll Free): 1 800 1110 1661
     Portugal (Toll Free): 800 819 575
     Romania (Toll Free): 0 800 410 029
     Russian Federation (Toll Free): 8 800 100 6203
     Saudi Arabia (Toll Free): 800 844 3633
     Singapore (Toll Free): 18007231323
     South Africa (Toll Free): 0 800 555 447
     Spain: +34 932 75 2004
     Sweden: +46 853 527 827
     Switzerland: +41 225 4599 78
     Taiwan (Toll Free): 0 800 666 854
     Thailand (Toll Free): 001 800 011 023
     Turkey (Toll Free): 00 800 4488 23683
     Ukraine (Toll Free): 0 800 50 1733
     United Arab Emirates (Toll Free): 800 044 40439
     Uruguay (Toll Free): 0004 019 1018
     Viet Nam (Toll Free): 122 80 481
    
     First GoToMeeting? Let's do a quick system check:
     https://link.gotomeeting.com/system-check
    
    
    




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Lars Kurth]

Hi all:
please add your agenda items. I had only ONE series which was highlighted as needing attention from others. Is this seriously the only one?
Regards
Lars

On 21/06/2019, 16:45, "Lars Kurth" <lars.kurth@citrix.com> wrote:

    Hi all,
        
    Please propose topics by either editing the running agenda document at https://cryptpad.fr/pad/#/2/pad/edit/V-JctV2vBlEnwliVLBlFLY7n/ or by replying to the mail.
    
    Note that currently I have
    * Nothing under: 
       D) New Series / Series that need attention / Series that are important
    * A prep item for the developer summit proposed by Jan at the last meeting
    I also made some progress on the code of conduct topic and am about to send a mail to xen-devel@
    
    Best Regards
    Lars
        
        == Dial-in Information ==
        
         ## Meeting time
         15:00 - 16:00 UTC
         Further International meeting times: 
         https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=6&day=27&hour=15&min=0&sec=0&p1=225&p2=224&p3=24&p4=179&p5=136&p6=37&p7=33
        
         ## Dial in details
         Web: https://www.gotomeet.me/larskurth
        
         You can also dial in using your phone.
         Access Code: 906-886-965
        
         China (Toll Free): 4008 811084
         Germany: +49 692 5736 7317
         Poland (Toll Free): 00 800 1124759
         United Kingdom: +44 330 221 0088
         United States: +1 (571) 317-3129
        
         More phone numbers
         Australia: +61 2 9087 3604
         Austria: +43 7 2081 5427
         Argentina (Toll Free): 0 800 444 3375
         Bahrain (Toll Free): 800 81 111
         Belarus (Toll Free): 8 820 0011 0400
         Belgium: +32 28 93 7018
         Brazil (Toll Free): 0 800 047 4906
         Bulgaria (Toll Free): 00800 120 4417
         Canada: +1 (647) 497-9391
         Chile (Toll Free): 800 395 150
         Colombia (Toll Free): 01 800 518 4483
          Czech Republic (Toll Free): 800 500448
         Denmark: +45 32 72 03 82
         Finland: +358 923 17 0568
         France: +33 170 950 594
         Greece (Toll Free): 00 800 4414 3838
         Hong Kong (Toll Free): 30713169
         Hungary (Toll Free): (06) 80 986 255
         Iceland (Toll Free): 800 7204
         India (Toll Free): 18002669272
         Indonesia (Toll Free): 007 803 020 5375
         Ireland: +353 15 360 728
         Israel (Toll Free): 1 809 454 830
         Italy: +39 0 247 92 13 01
         Japan (Toll Free): 0 120 663 800
         Korea, Republic of (Toll Free): 00798 14 207 4914
         Luxembourg (Toll Free): 800 85158
         Malaysia (Toll Free): 1 800 81 6854
         Mexico (Toll Free): 01 800 522 1133
         Netherlands: +31 207 941 377
         New Zealand: +64 9 280 6302
         Norway: +47 21 93 37 51
         Panama (Toll Free): 00 800 226 7928
         Peru (Toll Free): 0 800 77023
         Philippines (Toll Free): 1 800 1110 1661
         Portugal (Toll Free): 800 819 575
         Romania (Toll Free): 0 800 410 029
         Russian Federation (Toll Free): 8 800 100 6203
         Saudi Arabia (Toll Free): 800 844 3633
         Singapore (Toll Free): 18007231323
         South Africa (Toll Free): 0 800 555 447
         Spain: +34 932 75 2004
         Sweden: +46 853 527 827
         Switzerland: +41 225 4599 78
         Taiwan (Toll Free): 0 800 666 854
         Thailand (Toll Free): 001 800 011 023
         Turkey (Toll Free): 00 800 4488 23683
         Ukraine (Toll Free): 0 800 50 1733
         United Arab Emirates (Toll Free): 800 044 40439
         Uruguay (Toll Free): 0004 019 1018
         Viet Nam (Toll Free): 122 80 481
        
         First GoToMeeting? Let's do a quick system check:
         https://link.gotomeeting.com/system-check
        
        
        
    
    
    
    
    

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Rich Persaud]

> On Jun 25, 2019, at 12:36, Lars Kurth <lars.kurth@citrix.com> wrote:
> 
> Hi all:
> please add your agenda items. I had only ONE series which was highlighted as needing attention from others. Is this seriously the only one?

Proposed agenda item: in the absence of Jira tickets, would it be useful to have a list (e.g. generated by a script) with the lifecycle status of all outstanding patch series, e.g.

METADATA

- bug fix / improvement / refactor / cleanup / new feature
- impacted Xen subsystems/components/features
- targeted version of Xen
- contributing person/org
- relevance of patch series to the goals set by RM for the next Xen release
- related patch series (with below status info)

STATUS:

- patch series version
- date of patch series v1
- no responses received + ping count + days since submission + days since ping
- reviewed with objections
- reviewed without objections, awaiting ack
- acked, awaiting merge

From such a summary, patch series could be prioritized for review/triage in the community call, based on uniform criteria and project-wide context.

Rich
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Julien Grall]

Hi Rich,

On 6/25/19 8:38 PM, Rich Persaud wrote:
>> On Jun 25, 2019, at 12:36, Lars Kurth <lars.kurth@citrix.com> wrote:
>>
>> Hi all:
>> please add your agenda items. I had only ONE series which was highlighted as needing attention from others. Is this seriously the only one?
> 
> Proposed agenda item: in the absence of Jira tickets, would it be useful to have a list (e.g. generated by a script) with the lifecycle status of all outstanding patch series, e.g.
> 
> METADATA
> 
> - bug fix / improvement / refactor / cleanup / new feature
> - impacted Xen subsystems/components/features
> - targeted version of Xen
> - contributing person/org
> - relevance of patch series to the goals set by RM for the next Xen release
> - related patch series (with below status info)
> 
> STATUS:
> 
> - patch series version
> - date of patch series v1
> - no responses received + ping count + days since submission + days since ping
> - reviewed with objections
> - reviewed without objections, awaiting ack
> - acked, awaiting merge
> 
>  From such a summary, patch series could be prioritized for review/triage in the community call, based on uniform criteria and project-wide context.

While I think raising awareness of the stuck series is a good idea. I 
still have some concern regarding the prioritization. Who is going to 
consume the result of the discussion? Is it the maintainers?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Rich Persaud]

> On Jun 25, 2019, at 16:17, Julien Grall <julien.grall@arm.com> wrote:
> 
> Hi Rich,
> 
> On 6/25/19 8:38 PM, Rich Persaud wrote:
>>> On Jun 25, 2019, at 12:36, Lars Kurth <lars.kurth@citrix.com> wrote:
>>> 
>>> Hi all:
>>> please add your agenda items. I had only ONE series which was highlighted as needing attention from others. Is this seriously the only one?
>> Proposed agenda item: in the absence of Jira tickets, would it be useful to have a list (e.g. generated by a script) with the lifecycle status of all outstanding patch series, e.g.
>> METADATA
>> - bug fix / improvement / refactor / cleanup / new feature
>> - impacted Xen subsystems/components/features
>> - targeted version of Xen
>> - contributing person/org
>> - relevance of patch series to the goals set by RM for the next Xen release
>> - related patch series (with below status info)
>> STATUS:
>> - patch series version
>> - date of patch series v1
>> - no responses received + ping count + days since submission + days since ping
>> - reviewed with objections
>> - reviewed without objections, awaiting ack
>> - acked, awaiting merge
>> From such a summary, patch series could be prioritized for review/triage in the community call, based on uniform criteria and project-wide context.
> 
> While I think raising awareness of the stuck series is a good idea. I still have some concern regarding the prioritization. Who is going to consume the result of the discussion? Is it the maintainers?

Anyone who typically answers the question raised by Lars in this thread, presumably a subset of call attendees.

Rich
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Lars Kurth]

On 25/06/2019, 21:27, "Rich Persaud" <persaur@gmail.com> wrote:

    > On Jun 25, 2019, at 16:17, Julien Grall <julien.grall@arm.com> wrote:
    > 
    > Hi Rich,
    > 
    > On 6/25/19 8:38 PM, Rich Persaud wrote:
    >>> On Jun 25, 2019, at 12:36, Lars Kurth <lars.kurth@citrix.com> wrote:
    >>> 
    >>> Hi all:
    >>> please add your agenda items. I had only ONE series which was highlighted as needing attention from others. Is this seriously the only one?

We had quite a few additions to the agenda. One problem I have is that cryptpad history does not tell me who added an agenda item. We will have to manage this appropriately in the meeting.

    >> Proposed agenda item: in the absence of Jira tickets, would it be useful to have a list (e.g. generated by a script) with the lifecycle status of all outstanding patch series, e.g.
    >> METADATA
    >> - bug fix / improvement / refactor / cleanup / new feature
    >> - impacted Xen subsystems/components/features
    >> - targeted version of Xen
    >> - contributing person/org
    >> - relevance of patch series to the goals set by RM for the next Xen release
    >> - related patch series (with below status info)
    >> STATUS:
    >> - patch series version
    >> - date of patch series v1
    >> - no responses received + ping count + days since submission + days since ping
    >> - reviewed with objections
    >> - reviewed without objections, awaiting ack
    >> - acked, awaiting merge
    >> From such a summary, patch series could be prioritized for review/triage in the community call, based on uniform criteria and project-wide context.
    > 
    > While I think raising awareness of the stuck series is a good idea. I still have some concern regarding the prioritization. Who is going to consume the result of the discussion? Is it the maintainers?
    
    Anyone who typically answers the question raised by Lars in this thread, presumably a subset of call attendees.
    
This would only work if there was consensus on the priority amongst the key stake-holders. I believe that some limited prioritization has happened in the past, e.g. for some Arm related features for Xen 4.12 where, if I recall correctly you, Stefano and EPAM did this. 

Maybe we can trial this type of approach for a small number of series first. At the end of the day this is about queue management. Right now, when a new series comes in it ends up in one big queue (xen-devel@). Most complex series have to go through a series of gates (aka code reviews from different people) before they get applied and when a new version comes out the series ends up in the queue again: each reviewer today prioritizes their own review queues, where no-one else sees the prioritisation of other reviewers. Unless there is lot of spare review capacity (which there isn't) we essentially end up in grid-lock, with an ever-growing queue. We seem to have specific additional complexity in Xen because most recent series, typically involve a large number of reviewers.

In theory, there are several ways to address this:
* Queue management either by a set of agreed criteria which all reviewers follow or through some agreement about which series we actively try and shepherd through the gates
* We have an additional issue that in many areas we have multiple reviewers/committers reviewing the same area of code, which also frequently leads to slow-downs, because the multiple reviewers/committers can disagree. We could look at a model where the reviewers/committers agree that one takes the lead on reviewing a specific series. We could try and streamline the ownership structure to create a clearer mapping.
* The queues of each reviewer are somehow made public (assuming this is possible) and we hope that the system self-regulates. Not sure this will actually work

The big problem I have is that mailing lists really don't lend themselves well to highlight what is going on. We have been grappling with this for years and things are getting worse, not better.

In past community calls when we tried to do this with specific series, in practice we ended up discovering obstacles that were concerning a specific series, such as unexposed dependencies, lack of HW, specs against which to review being too complex, ...

In any case, given that quite a few series were added to the agenda, maybe we shouldn't talk about process in the meeting, but see whether we can unblock those series. I am going to annotate some of the agenda items to highlight WHO needs to take action on items added

We could have a wider discussion about the process at the summit, as everyone who would need to be involved is at the summit. 

Regards
Lars



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Rich Persaud]

> On Jun 26, 2019, at 06:45, Lars Kurth <lars.kurth@citrix.com> wrote:
> 
> 
> 
> On 25/06/2019, 21:27, "Rich Persaud" <persaur@gmail.com> wrote:
> 
>> On Jun 25, 2019, at 16:17, Julien Grall <julien.grall@arm.com> wrote:
>> 
>> Hi Rich,
>> 
>> On 6/25/19 8:38 PM, Rich Persaud wrote:
>>>> On Jun 25, 2019, at 12:36, Lars Kurth <lars.kurth@citrix.com> wrote:
>>>> 
>>>> Hi all:
>>>> please add your agenda items. I had only ONE series which was highlighted as needing attention from others. Is this seriously the only one?
> 
> We had quite a few additions to the agenda. One problem I have is that cryptpad history does not tell me who added an agenda item. We will have to manage this appropriately in the meeting.
> 
>>> Proposed agenda item: in the absence of Jira tickets, would it be useful to have a list (e.g. generated by a script) with the lifecycle status of all outstanding patch series, e.g.
>>> METADATA
>>> - bug fix / improvement / refactor / cleanup / new feature
>>> - impacted Xen subsystems/components/features
>>> - targeted version of Xen
>>> - contributing person/org
>>> - relevance of patch series to the goals set by RM for the next Xen release
>>> - related patch series (with below status info)
>>> STATUS:
>>> - patch series version
>>> - date of patch series v1
>>> - no responses received + ping count + days since submission + days since ping
>>> - reviewed with objections
>>> - reviewed without objections, awaiting ack
>>> - acked, awaiting merge
>>> From such a summary, patch series could be prioritized for review/triage in the community call, based on uniform criteria and project-wide context.
>> 
>> While I think raising awareness of the stuck series is a good idea. I still have some concern regarding the prioritization. Who is going to consume the result of the discussion? Is it the maintainers?
> 
>   Anyone who typically answers the question raised by Lars in this thread, presumably a subset of call attendees.
> 
> This would only work if there was consensus on the priority amongst the key stake-holders. I believe that some limited prioritization has happened in the past, e.g. for some Arm related features for Xen 4.12 where, if I recall correctly you, Stefano and EPAM did this. 
> 
> Maybe we can trial this type of approach for a small number of series first. At the end of the day this is about queue management. Right now, when a new series comes in it ends up in one big queue (xen-devel@). Most complex series have to go through a series of gates (aka code reviews from different people) before they get applied and when a new version comes out the series ends up in the queue again: each reviewer today prioritizes their own review queues, where no-one else sees the prioritisation of other reviewers. Unless there is lot of spare review capacity (which there isn't) we essentially end up in grid-lock, with an ever-growing queue. We seem to have specific additional complexity in Xen because most recent series, typically involve a large number of reviewers.
> 
> In theory, there are several ways to address this:
> * Queue management either by a set of agreed criteria which all reviewers follow or through some agreement about which series we actively try and shepherd through the gates
> * We have an additional issue that in many areas we have multiple reviewers/committers reviewing the same area of code, which also frequently leads to slow-downs, because the multiple reviewers/committers can disagree. We could look at a model where the reviewers/committers agree that one takes the lead on reviewing a specific series. We could try and streamline the ownership structure to create a clearer mapping.
> * The queues of each reviewer are somehow made public (assuming this is possible) and we hope that the system self-regulates. Not sure this will actually work
> 
> The big problem I have is that mailing lists really don't lend themselves well to highlight what is going on. We have been grappling with this for years and things are getting worse, not better.
> 
> In past community calls when we tried to do this with specific series, in practice we ended up discovering obstacles that were concerning a specific series, such as unexposed dependencies, lack of HW, specs against which to review being too complex, ...
> 
> In any case, given that quite a few series were added to the agenda, maybe we shouldn't talk about process in the meeting, but see whether we can unblock those series. I am going to annotate some of the agenda items to highlight WHO needs to take action on items added
> 
> We could have a wider discussion about the process at the summit, as everyone who would need to be involved is at the summit.

This has likely been raised before, but ... could the Xen community use Github/Gitlab PRs to reduce the overhead of managing a review queue?  PR-based workflows have helped open-source projects to better utilize teams for review queue management.

PRs could be used in parallel with the existing mailing list patch process.  To link the two workflows, PR review comments could be mirrored to the mailing list, and a link to the PR included in the first patch of the series revisions.

If PRs are used, Jira can automatically link PRs that are associated with a XEN-nnnn ticket number.  With  PR comment mirroring, the mailing list would remain the definitive archive of review comments.  There may also be opportunities for integration with Xen's Gitlab CI, e.g. series testing on multiple architectures.

Rich
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 6142 bytes --]

On Wed, 26 Jun 2019, Rich Persaud wrote:
> > On Jun 26, 2019, at 06:45, Lars Kurth <lars.kurth@citrix.com> wrote:
> > 
> > 
> > 
> > On 25/06/2019, 21:27, "Rich Persaud" <persaur@gmail.com> wrote:
> > 
> >> On Jun 25, 2019, at 16:17, Julien Grall <julien.grall@arm.com> wrote:
> >> 
> >> Hi Rich,
> >> 
> >> On 6/25/19 8:38 PM, Rich Persaud wrote:
> >>>> On Jun 25, 2019, at 12:36, Lars Kurth <lars.kurth@citrix.com> wrote:
> >>>> 
> >>>> Hi all:
> >>>> please add your agenda items. I had only ONE series which was highlighted as needing attention from others. Is this seriously the only one?
> > 
> > We had quite a few additions to the agenda. One problem I have is that cryptpad history does not tell me who added an agenda item. We will have to manage this appropriately in the meeting.
> > 
> >>> Proposed agenda item: in the absence of Jira tickets, would it be useful to have a list (e.g. generated by a script) with the lifecycle status of all outstanding patch series, e.g.
> >>> METADATA
> >>> - bug fix / improvement / refactor / cleanup / new feature
> >>> - impacted Xen subsystems/components/features
> >>> - targeted version of Xen
> >>> - contributing person/org
> >>> - relevance of patch series to the goals set by RM for the next Xen release
> >>> - related patch series (with below status info)
> >>> STATUS:
> >>> - patch series version
> >>> - date of patch series v1
> >>> - no responses received + ping count + days since submission + days since ping
> >>> - reviewed with objections
> >>> - reviewed without objections, awaiting ack
> >>> - acked, awaiting merge
> >>> From such a summary, patch series could be prioritized for review/triage in the community call, based on uniform criteria and project-wide context.
> >> 
> >> While I think raising awareness of the stuck series is a good idea. I still have some concern regarding the prioritization. Who is going to consume the result of the discussion? Is it the maintainers?
> > 
> >   Anyone who typically answers the question raised by Lars in this thread, presumably a subset of call attendees.
> > 
> > This would only work if there was consensus on the priority amongst the key stake-holders. I believe that some limited prioritization has happened in the past, e.g. for some Arm related features for Xen 4.12 where, if I recall correctly you, Stefano and EPAM did this. 
> > 
> > Maybe we can trial this type of approach for a small number of series first. At the end of the day this is about queue management. Right now, when a new series comes in it ends up in one big queue (xen-devel@). Most complex series have to go through a series of gates (aka code reviews from different people) before they get applied and when a new version comes out the series ends up in the queue again: each reviewer today prioritizes their own review queues, where no-one else sees the prioritisation of other reviewers. Unless there is lot of spare review capacity (which there isn't) we essentially end up in grid-lock, with an ever-growing queue. We seem to have specific additional complexity in Xen because most recent series, typically involve a large number of reviewers.
> > 
> > In theory, there are several ways to address this:
> > * Queue management either by a set of agreed criteria which all reviewers follow or through some agreement about which series we actively try and shepherd through the gates
> > * We have an additional issue that in many areas we have multiple reviewers/committers reviewing the same area of code, which also frequently leads to slow-downs, because the multiple reviewers/committers can disagree. We could look at a model where the reviewers/committers agree that one takes the lead on reviewing a specific series. We could try and streamline the ownership structure to create a clearer mapping.
> > * The queues of each reviewer are somehow made public (assuming this is possible) and we hope that the system self-regulates. Not sure this will actually work
> > 
> > The big problem I have is that mailing lists really don't lend themselves well to highlight what is going on. We have been grappling with this for years and things are getting worse, not better.
> >
> > In past community calls when we tried to do this with specific series, in practice we ended up discovering obstacles that were concerning a specific series, such as unexposed dependencies, lack of HW, specs against which to review being too complex, ...
> > 
> > In any case, given that quite a few series were added to the agenda, maybe we shouldn't talk about process in the meeting, but see whether we can unblock those series. I am going to annotate some of the agenda items to highlight WHO needs to take action on items added
> > 
> > We could have a wider discussion about the process at the summit, as everyone who would need to be involved is at the summit.
> 
> This has likely been raised before, but ... could the Xen community use Github/Gitlab PRs to reduce the overhead of managing a review queue?  PR-based workflows have helped open-source projects to better utilize teams for review queue management.
> 
> PRs could be used in parallel with the existing mailing list patch process.  To link the two workflows, PR review comments could be mirrored to the mailing list, and a link to the PR included in the first patch of the series revisions.
> 
> If PRs are used, Jira can automatically link PRs that are associated with a XEN-nnnn ticket number.  With  PR comment mirroring, the mailing list would remain the definitive archive of review comments.  There may also be opportunities for integration with Xen's Gitlab CI, e.g. series testing on multiple architectures.

Yes, this has been brought up in the past, and the majority (me
included) preferred doing doing reviews on a mailing list. However,
patchworks has been getting better and better and should now be able to
give you a github-like web interface to patch series submissions and
reviews while retaining the mailing list based workflow most still
prefer. I know patchworks has also been used to trigger testing by some.
I don't know the state of the patchworks instance for Xen.

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen Project Community Call June 27th (instead of July 4th): @15:00 UTC Call for agenda items

[Lars Kurth]

On 26/06/2019, 18:44, "Stefano Stabellini" <sstabellini@kernel.org> wrote:

    On Wed, 26 Jun 2019, Rich Persaud wrote:
    > > On Jun 26, 2019, at 06:45, Lars Kurth <lars.kurth@citrix.com> wrote:
    > > 
    > > 
    > > 
    > > On 25/06/2019, 21:27, "Rich Persaud" <persaur@gmail.com> wrote:
    > > 
    > >> On Jun 25, 2019, at 16:17, Julien Grall <julien.grall@arm.com> wrote:
    > >> 
    > >> Hi Rich,
    > >> 
    > >> On 6/25/19 8:38 PM, Rich Persaud wrote:
    > >>>> On Jun 25, 2019, at 12:36, Lars Kurth <lars.kurth@citrix.com> wrote:
    > >>>> 
    > >>>> Hi all:
    > >>>> please add your agenda items. I had only ONE series which was highlighted as needing attention from others. Is this seriously the only one?
    > > 
    > > We had quite a few additions to the agenda. One problem I have is that cryptpad history does not tell me who added an agenda item. We will have to manage this appropriately in the meeting.
    > > 
    > >>> Proposed agenda item: in the absence of Jira tickets, would it be useful to have a list (e.g. generated by a script) with the lifecycle status of all outstanding patch series, e.g.
    > >>> METADATA
    > >>> - bug fix / improvement / refactor / cleanup / new feature
    > >>> - impacted Xen subsystems/components/features
    > >>> - targeted version of Xen
    > >>> - contributing person/org
    > >>> - relevance of patch series to the goals set by RM for the next Xen release
    > >>> - related patch series (with below status info)
    > >>> STATUS:
    > >>> - patch series version
    > >>> - date of patch series v1
    > >>> - no responses received + ping count + days since submission + days since ping
    > >>> - reviewed with objections
    > >>> - reviewed without objections, awaiting ack
    > >>> - acked, awaiting merge
    > >>> From such a summary, patch series could be prioritized for review/triage in the community call, based on uniform criteria and project-wide context.
    > >> 
    > >> While I think raising awareness of the stuck series is a good idea. I still have some concern regarding the prioritization. Who is going to consume the result of the discussion? Is it the maintainers?
    > > 
    > >   Anyone who typically answers the question raised by Lars in this thread, presumably a subset of call attendees.
    > > 
    > > This would only work if there was consensus on the priority amongst the key stake-holders. I believe that some limited prioritization has happened in the past, e.g. for some Arm related features for Xen 4.12 where, if I recall correctly you, Stefano and EPAM did this. 
    > > 
    > > Maybe we can trial this type of approach for a small number of series first. At the end of the day this is about queue management. Right now, when a new series comes in it ends up in one big queue (xen-devel@). Most complex series have to go through a series of gates (aka code reviews from different people) before they get applied and when a new version comes out the series ends up in the queue again: each reviewer today prioritizes their own review queues, where no-one else sees the prioritisation of other reviewers. Unless there is lot of spare review capacity (which there isn't) we essentially end up in grid-lock, with an ever-growing queue. We seem to have specific additional complexity in Xen because most recent series, typically involve a large number of reviewers.
    > > 
    > > In theory, there are several ways to address this:
    > > * Queue management either by a set of agreed criteria which all reviewers follow or through some agreement about which series we actively try and shepherd through the gates
    > > * We have an additional issue that in many areas we have multiple reviewers/committers reviewing the same area of code, which also frequently leads to slow-downs, because the multiple reviewers/committers can disagree. We could look at a model where the reviewers/committers agree that one takes the lead on reviewing a specific series. We could try and streamline the ownership structure to create a clearer mapping.
    > > * The queues of each reviewer are somehow made public (assuming this is possible) and we hope that the system self-regulates. Not sure this will actually work
    > > 
    > > The big problem I have is that mailing lists really don't lend themselves well to highlight what is going on. We have been grappling with this for years and things are getting worse, not better.
    > >
    > > In past community calls when we tried to do this with specific series, in practice we ended up discovering obstacles that were concerning a specific series, such as unexposed dependencies, lack of HW, specs against which to review being too complex, ...
    > > 
    > > In any case, given that quite a few series were added to the agenda, maybe we shouldn't talk about process in the meeting, but see whether we can unblock those series. I am going to annotate some of the agenda items to highlight WHO needs to take action on items added
    > > 
    > > We could have a wider discussion about the process at the summit, as everyone who would need to be involved is at the summit.
    > 
    > This has likely been raised before, but ... could the Xen community use Github/Gitlab PRs to reduce the overhead of managing a review queue?  PR-based workflows have helped open-source projects to better utilize teams for review queue management.
    > 
    > PRs could be used in parallel with the existing mailing list patch process.  To link the two workflows, PR review comments could be mirrored to the mailing list, and a link to the PR included in the first patch of the series revisions.
    > 
    > If PRs are used, Jira can automatically link PRs that are associated with a XEN-nnnn ticket number.  With  PR comment mirroring, the mailing list would remain the definitive archive of review comments.  There may also be opportunities for integration with Xen's Gitlab CI, e.g. series testing on multiple architectures.
    
    Yes, this has been brought up in the past, and the majority (me
    included) preferred doing doing reviews on a mailing list. However,
    patchworks has been getting better and better and should now be able to
    give you a github-like web interface to patch series submissions and
    reviews while retaining the mailing list based workflow most still
    prefer. I know patchworks has also been used to trigger testing by some.
    I don't know the state of the patchworks instance for Xen.

As far as I recall Wei has looked at both patchwork (https://patchwork.kernel.org/project/xen-devel/list/) and :patchew (https://patchew.org/Xen) for the purpose of looking at triggers. I recall he sent a summary mail, but I can't find it. As far as I recall :patchew was deemed nicer, as it retains the cover letter of patches in most cases.

We will need to decide for one or the other at the summit, as we need this to trigger GitLabCi build and smoke tests (QEMU based) from patches posted to the list. 

Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel