On Tue, Nov 10, 2020 at 05:01:34PM +0100, Philippe Mathieu-Daudé wrote: > When a job fails, someone has to take care of it. As we can > not wait indefinitively of volunteers good will, introduce the > concept of "job maintainers". A job maintainer is reponsible > of keeping it working, or contact the developers having broken > it to fix it. > > When a job is added, it must have a maintainer. A job without > maintainer is not run automatically. It can however be run > manually from the WebUI. > > To declare a maintainer, it is as easy as defining the > JOB_MAINTAINER_NAME / JOB_MAINTAINER_EMAIL environment variables.
I don't think we really want/need todo this. The big problem we're facing is that there is no incentive right now for maintainers to make sure their code works with GitLab CI before they send a pull request. Adding job maintainers is just a band-aid, and not a very good one either, because each job covers features across many subsystems which should each be dealt with by their existing maintainers. The primary solution to this tragedy is to make all the jobs gating on all pull requests. If a maintainer wants their pull requrst to get merged they then have no choice but to ensure it doesn't break any CI jobs. The main blocker for this right now IIUC is the git repo sync from qemu to gitlab. Once we switch to gitlab as primary, we need to start enforcing GitLab as gating for all jobs. At this point making sure GitLab CI passes is every maintainer's job. We'll still have some failures periodically from non-deterministic bugs. If a test shows itself to be flaky though, it should just be disabled in a very short time frame. Whichever maintainer owned the test has the job for fixing the flakyness before it can be renabled. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
