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

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

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

    > On Jun 25, 2019, at 16:17, Julien Grall <julien.grall@xxxxxxx> wrote:
    > 
    > Hi Rich,
    > 
    > On 6/25/19 8:38 PM, Rich Persaud wrote:
    >>> On Jun 25, 2019, at 12:36, Lars Kurth <lars.kurth@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel