Re: [oniro-dev] Use GitLab merge trains to optimize development workflow

[Amit Kucheria <amit.kucheria.ext@xxxxxxxxxx>]

Thanks for raising this, Esben.

While I too am on the 'linear history' side of the fence, our current contention levels for CI resources and wasted developer time in playing the merge roulette is indeed a problem. 

Merge trains with fast-forward won't land until 2024 (2023Q4 in code, then roll out to EF). So we'll be effectively spending the next 18 months with this with the option to roll back if things don't work out.

While I think we should try merge trains out, I'm a little concerned about the timing as we're trying to land things for Beta slate for end of September.

I like Zyga's idea of trying it out on a copy somewhere, ensure CI is working before we enable it on the main Oniro repo.
 
> -----Original Message-----
> From: oniro-dev [mailto:oniro-dev-bounces@xxxxxxxxxxx] On Behalf Of Esben
> Haabendal
> Sent: 17 August 2022 19:55
> To: oniro-dev@xxxxxxxxxxx
> Subject: [oniro-dev] Use GitLab merge trains to optimize development
> workflow
> 
> Hi
> 
> 
> 
> With this email, I would like to come with a proposal to use GitLab merge
> trains to optimize the development workflow when working on Oniro
> repository.
> 
> 
> 
> Please read it through, and reply back with what you think.  Hate it?  Love it?
> Let's do this now!?  Concerns?  Anything that is unclear?
> 
> 
> 
> Problem:
> 
> 
> 
> Currently, developers contributing to eclipse/oniro-core/oniro repository are
> going through a rough time.  In order to get something merged, the MR
> needs to be rebased to the current (kirkstone) branch HEAD.  So when
> multiple MR are trying to get merged at the same time, the MR that gets
> merged first wins.
> 
> All the rest will have to rebase to the new HEAD, and run a completely new
> pipeline.  When enough MRs are pending at the same time, it effectively
> becomes a time consuming Whack-a-mole game.
> 
> 
> 
> Not only does this cost developer time, as developer needs to keep an eye
> on the MR progress, and do rebasing as needed to hopefully win out at get
> merged first at some point in time.  But CI will end up being loaded more
> than needed, as many MR ends up being run through its complete pipeline
> several times before it is merged.
> 
> 
> 
> And finally, calendar time is impacted heavily, as the time needed to get a
> MR merged is unpredictable and much larger than what should be expected.
> 
> 
> 
> Solution:
> 
> 
> 
> Enable GitLab merge trains.  See
> 
> https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html
> 
> 
> 
> This allows multiple pending MRs to be processed by CI in proper order, so
> that if all MR pipelines succeed, only one pipeline per MR will be run, and no
> developer interaction will be needed.
> 
> 
> 
> So it saves calendar time, CI resources and developer time.
> 
> 
> 
> As a consequence, the current implementation of GitLab merge trains
> requires use of merge commits, so the oniro repository will switch from fast-
> forward merges (linear history) to to using merge commits.