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

[Rich Persaud <persaur@xxxxxxxxx>]

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.

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