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

Reply via email to