Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf
> Of Rich Persaud
> Sent: 11 July 2018 15:06
> To: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Cc: committers@xxxxxxxxxxxxxx; Lars Kurth <lars.kurth@xxxxxxxxxx>;
> cardoe@xxxxxxxxxx; George Dunlap <George.Dunlap@xxxxxxxxxx>; Tamas K
> Lengyel <tamas.k.lengyel@xxxxxxxxx>
> Subject: Re: [Xen-devel] [Notes for xen summit 2018 design session] Process
> changes: is the 6 monthly release Cadence too short, Security Process, ...
> 
> On Jul 5, 2018, at 22:54, Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>
> wrote:
> >
> >> On Thu, Jul 5, 2018 at 12:52 PM George Dunlap
> <George.Dunlap@xxxxxxxxxx> wrote:
> >>
> >>>
> >>>> Again, there was a sense that some of the issues we are seeing could
> be solved if we had better
> >>>> CI capability: in other words, some of the issues we were seeing could
> be resolved by
> >>>> * Better CI capability as suggested in the Release Cadence discussion
> >>>> * Improving some of the internal working practices of the security team
> >>>> * Before we commit to a change (such as improved batching), we
> should try them first informally.
> >>>>  E.g. the security team could try and work towards more predictable
> dates for batches vs. a
> >>>>  concrete process change
> >>>
> >>> My feeling on CI is clear in this thread and other threads. But I think
> >>> what would help OSSTEST bottlenecks if we do better at separating up
> >>> different parts of the testing process into more parallel tasks that
> >>> also provide feedback to the contributor faster. I'll obviously never
> >>> suggest the GitHub/GitLab PR/MR model to a ML driven project because
> I
> >>> wouldn't survive the hate mail but there is something that those models
> >>> do provide.
> >>
> >> FWIW we (IanJ, Wei, Roger, Anthony and I) just had a fairly extended
> discussion about this in our team meeting today, and everyone basically
> agreed that there are some things about the web-based PR model that are
> *really* nice:
> >>
> >> 1. Effective tracking of submission state — open / assigned to a reviewer /
> merged / rejected
> >> 2. Automation
> >> 3. Not having to marshal git commits into email, and then marshal them
> back into git commits again
> >>
> >> On the other hand, the general consensus, from people who had used
> such websites “in anger” (as they say here in the UK) was that they really
> didn’t like the way that reviews worked.  Email was seen as:
> >> 1. Much more convenient for giving feedback and having discussions
> >> 2. Easier for people to “listen in” on other people’s reviews
> >> 3. More accessible for posterity
> >>
> >> In the end we generally agreed that it was an idea worth thinking about
> more.  Not sure how the wider community feels, but there are at least a
> decent cohort who wouldn’t send you hate mail. :-)
> >
> > I for one would very much welcome a PR-style model. Keeping track of
> > patches in emails I need to review is not fun (and I'm pretty bad at
> > it) and then just to find a patch that doesn't even compile is a waste
> > of everyone's time. Automatic style checks and compile checks are the
> > bare minimum I would consider any project should have today. There is
> > already a Travis CI script shipped with Xen yet it's not used when
> > patches are submitted.. Perhaps the reviews are more accessible for
> > posterity but I personally never end up reading old reviews, even in
> > the depths of the worst code archeology it's always just looking at
> > git blame and commit messages. Giving feedback and discussions I also
> > find a lot more easier to navigate on say Github then on the
> > mailinglist - and I do get email copies of PRs and can reply inline
> > via email if I want to.. We are already keeping track of open patch
> > series on Jira - or at least there was an attempt to do so, not sure
> > how up-to-date that is - but that's not the right way as that requires
> > manual porting of tasks from the mailinglist. Perhaps it should be the
> > other way around.
> >
> > Just my 2c.
> >
> > Tamas
> 
> OpenXT uses JIRA for issue tracking and Github for pull requests and
> approval workflow.  JIRA can link  issues to PRs, based on ticket number in
> the PR description.
> 
> Both JIRA and Github can mirror  issue/PR comments and content to email
> (individual or mailing list).  Replies to these emails will be associated with
> issues/PRs, if the sender has an account on the service.
> 
> Would there be interest in testing a Gitlab/Github workflow in a Xen sub
> project, where contributors are already inclined to use such tools?   Windows
> PV drivers could be a candidate, as QubesOS uses Github PRs and the volume
> of changes is not high.
> 

Personally I'm not a fan of web based workflows. I think that mailing lists 
work much better for review as my experience of using web review tools has been 
that it is nearly impossible to comment on a patch as a whole and when comments 
are mirrored to email they end up some sort of digest in reverse chronological 
order. That said, pulling the final reviewed code from a branch is certainly 
much easier than applying patches from a mailbox.

  Paul

> The value of these services is not just the metadata archive and structure
> that it brings to dev workflow, but the ever-expanding ecosystem of
> analytics tools that can use the  historical data.  Yes, in theory, similar 
> data can
> be extracted from xen-devel archives, but it often requires custom tooling.
> Case in point - the lack of accessible quantitative data to substantiate the
> intuitions expressed in this thread, about the differences in dev patterns
> with 6-month vs. longer release cycles.
> 
> Rich
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel