On 4/25/19 1:33 PM, Jan Beulich wrote: >> With this system, all published commits should have already passed Gitlab CI >> and osstest tests. > > While this is certainly desirable as a goal, is the problem of > occasional build issues really this big, warranting introduction > of further overhead?
You seem to have missed the conjuction at the end of the sentence you're relpying to: "...and osstest tests". It's not mainly to stop occasional build issues; it's to stop long-running pushgate failures. >> ## Concerns >> >> For individual committers, turnaround time may become longer since you need >> to >> wait for other trees to be processed. > > Together with this larger latency, chances increase that two > committers pick up the same patch or series. With today's > single central instance everyone pushes to it is at least > possible to check whether something has gone in already > before starting to commit things. Iirc whenever I ended up > trying to commit a patch that was already there, it was > because of me not having checked (again), rather than > because of an actual race. If this becomes an issue, I'm sure we can sort out a technical solution. A pre-push script that checks other "open" submissions for duplicates shouldn't be difficult to implement. Having a unified place for committers to simply approve posts for merging (rather than submitting a pull request) would be a longer-term improvement. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel