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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 26 Jun 2019, Rich Persaud wrote:
> > On Jun 26, 2019, at 06:45, Lars Kurth <lars.kurth@xxxxxxxxxx> wrote:
> > 
> > 
> > 
> > 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.
> 
> 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.

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