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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 5 Jul 2018, George Dunlap 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. :-)

A properly run patchwork instance is supposed to be able to give us many
of the benefits of the web PR model while retaining the benefits of the
ML based model.

For instance, at Xen Summit we discussed the possibility of running
automated tests on submitted patch series, before they are even
reviewed. The purpose is to free up reviewers' time. Obviously, we don't
need web PRs to enable this, given that both the Linux kernel and QEMU
already have something along those lines, however, we do need a way to
recognize patch series submissions and run something in response to
them. I don't know what Intel is using for the Linux kernel but maybe it
is something based on patchworks? We had an action item to get in touch
with them and ask.

Of course, if we don't even have the test bandwidth to do releases,
testing un-reviewed patch series is not really a priority right now.
However, these tests wouldn't be done on OSSTest, they could be done
with the aforementioned GitLab infrastructure; they are independent.

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