Re: MergeRequest process (bot) update

On Mon, Jan 31, 2022, at 17:55, Rémi Denis-Courmont wrote:
> 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).

cf. my other answer email.

>
> 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.

Okay, sounds legit to put it in Accepted after 72h. I will try to propose something.

>
> 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.

Same here, the bot should probably ignore this. Noted in my todo.

> 4) Contrib sources (contrib/tarballs) should be cached across pipelines.
>
> 5) Contrib should use ccache like main build.

Contrib management in CI probably needs some love, indeed.
I can remember there have been some discussions during the CI setup about non monolithic prebuilts, but the subject had been postponed at the time.
I am still unsure if the contrib system could be modified to have some kind of incremental/dependency-aware prebuilts - or if ccache would magically do more or less the same job.

>
> 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.)
>

No real fixed opinion about CI priority to be honest.
I thought VLC CI was more about checking build regression on main user platfforms, but coverage is also an important strategy.

Regards,

> -- 
> レミ・デニ-クールモン
> http://www.remlab.net/
>
>
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel


-- 
Simon Latapie
[email protected]
_______________________________________________
vlc-devel mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc-devel