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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Wei Liu writes ("Re: [Xen-devel] [Notes for xen summit 2018 design session] 
Process changes: is the 6 monthly release Cadence too short, Security Process, 
..."):
> It is more the case that one incomplete fix blocks all other valid
> fixes, so the time from staging to msater is even longer.
> 
> (The record in this case is 100 patches between staging and master and
> exactly 1 calendar month to get a push)

One possibility would be to split osstest's input queues up.

Currently, osstest uses an unusual model, compared to many other CI
systems: by and large the input branches to osstest are
fast-forwarding.  I don't operate this way with osstest itself.  I
allow myself to rewind osstest pretest (the equivalent of staging)
whenever it seems appropriate.

The result is that if maintainer X pushes a bad series, the only way
to move forward is to fix it or revert it.

An alternative model would be that each batch of work is prepared by
committers separately, and only becomes part of public master after it
has been tested.

Obviously this would divide osstest bandwidth between the batches, so
each batch would have to wait longer for a test.  But it does mean
that if a batch produces a test failure, no-one else is blocked, and
the batch can be reworked.

If this is an interesting idea we should talk about what more
precisely it would look like.

Ian.

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