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

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 03/07/2018, 11:01, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

    >>> On 03.07.18 at 10:06, <lars.kurth@xxxxxxxxxx> wrote:
    > The GitLab discussion was really interesting. Looking at OSSTEST, it 
    > basically performs build test and integration tests on Hardware. Whereas 
all 
    > these are needed, build testing and testing of functionality that does 
not 
    > depend on hardware could be done earlier. The ghist of the GitLab 
discussion 
    > was to "move" build testing - and possibly some basic integration testing 
- 
    > to the point of submitting a patch. The basic flow is:
    > * Someone posts a patch to the list => this will start the GitLab 
machinery 
    > * The Gitlab machinery will do build tests (and the discussion showed 
that 
    > we should be able to do this via cross compilation or compilation on a 
real 
    > system if a service such as infosifter is used - @Matt: I can't find the 
    > company via Google, maybe the spelling in the minutes is wrong)
    > * This could eventually include a basic set of smoke tests that are 
system 
    > independent and could run under QEMU - Doug already uses a basic test 
where a 
    > xen host and/or VM is started 
    > * If it fails, a mail is sent in reply to the patch submission by a bot - 
    > that piece has been developed by Intel for QEMU and Linux and could be 
    > re-used
    > 
    > This would free up time by reviewers and also leads to issues found 
earlier. 
    > In other words, OSSTEST would merely re-test what had been tested earlier 
and 
    > would focus on testing on real hardware. Thus, OSSTEST failures should 
become 
    > less likely. But obviously implementing such a system, even though all 
the 
    > pieces for it exist, will take some time.
    
    But the problem is rarely with actual build issues, and much more
    frequently with other hickups. Plus osstest re-testing what had already
    been tested elsewhere is not going to help osstest's bandwidth. Yet with
    now 6 stable branches regularly needing testing, bandwidth is an issue.
    
OK, I didn't realize bandwidth is the primary issue. If it is, we can fix this 
part by throwing more HW at the problem.
Let me have a chat with Ian when I am in the office and come up with a list of 
issues from his perspective and feed this back into the thread.

Lars
    
    
    

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