[vlc-devel] MergeRequest process (bot) update

Rémi Denis-Courmont remi at remlab.net
Mon Jan 31 16:55:32 UTC 2022


Le maanantaina 31. tammikuuta 2022, 18.27.32 EET Simon Latapie a écrit :
> > It remains somewhat unclear to me what happens to patches that are not
> > considered reviewed at all, and to those with all threads resolved but no
> > votes nor approvals.
> 
> Right now, what is supposed to be "implemented", either in term of human
> process or bot script: - MRs from VLC Developers (in term of gitlab role -
> aka people that have the right to merge) that are not considered reviewed
> at all for a certain amount of time (72h for now) are considered Accepted -
> aka mergeable. - MRs from VLC Developers that have some threads resolved
> but with a Score of zero (so no approval with the new scoring method) are
> considered Acceptable, then Accepted 24h after the last thread resolve.
> 
> - MRs from external contributors *must* have both a strictly positive score
> (at least an approval from a Developer) and all threads resolved to be
> Acceptable, and the MR will become Accepted after 72h.
> 
> If you have any suggestion that could ease the MR authors or reviewers
> experience, do not hesitate to propose. I will try to do my best to help
> you on that.

1) The actual review statusis concealed if the last CI pipeline failed (for 
both good and bad reasons).

2) If a patch is only reviewed in the interval between 48 and 72 hours, 
acceptance is further postponed, even if the review was an up-vote or an 
approval.

3) If a patch is reviewed past 72 hours in reviewable state, it goes from 
accepted to acceptable state for 24 hours, even if the review was merely a 
late up-vote or approval.

4) Contrib sources (contrib/tarballs) should be cached across pipelines.

5) Contrib should use ccache like main build.

6) CI targets need to be rationalised. We have some targets that are frequent 
bottlenecks and yet bring nigh-zero additional coverage due to overlap with 
other targets. (Conversely, we could add targets that increase coverage way 
more.)

-- 
レミ・デニ-クールモン
http://www.remlab.net/





More information about the vlc-devel mailing list