[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [oniro-dev] Use GitLab merge trains to optimize development workflow
|
I'll use this chance to respond to the thread I don't have the initial
message of.
On 18-Aug-22 17:36, Andrei Gherzan wrote:
Hi all,
The only downside of this approach is losing fast-forward merges but on
the other hand, this seems to be planned in GitLab development so
hopefully, it will be just a flick of a button when it lands:
https://gitlab.com/groups/gitlab-org/-/epics/4911
Nevertheless, given the current pain of merging things I completely
support this trade-off. This issue is more apparent in repositories
where there is a greater level of concurrency – and probably the `oniro`
repository is the worst affected. Here, merge requests can easily take
2-4 days to just catch a merge chance. This slow CI feedback and the
constant need to keep an eye on your merge requests create an
unreasonable development overhead.
I second this opinion. We are not getting married here, we can revert
this later on, or opt-into fast-forward merges when the stack supports that.
I would suggest that we create a fork of oniro.git somewhere, enable the
option there, send a few MRs and see how it behaves, so that we don't
have any last-minute surprises when this is enabled in the "production"
copy of oniro.git.
Our CI pipelines do some creative things to support manifest-based
workflows, so it's not out of the question that this will break and will
need adjustments.
Best regards
ZK
