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

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

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

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