qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 10/16] gitlab-ci: Introduce the CI "job maintainer" conce


From: Philippe Mathieu-Daudé
Subject: Re: [RFC PATCH 10/16] gitlab-ci: Introduce the CI "job maintainer" concept
Date: Wed, 11 Nov 2020 12:13:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 11/11/20 10:45 AM, Daniel P. Berrangé wrote:
> 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.

At this point I'd rather remove everything we have in CI and restart
from scratch. So if someone is really interested in having CI jobs /
runner, this someone will step in and contribute / maintain. Not like
the current state when some are happy to use the result, but nobody
cares about maintenance or fixing bugs (as the last year experience
clearly show).

I don't know if Alex / Thomas are willing to keep doing that.

I personally don't have the the energy to do this in my spare time.

Thanks.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]