Andrew, and anyone,
Can anyone more deeply explain why ONAP is striving to avoid branching/merging
in its git flow?
Andrew, Can you detail a specific limitation that will help me come to terms
with this policy? I hope you can break this down because I cannot get my head
around it: "It's something that can be enabled but it breaks the workflow that
Gerrit is striving for in that a single change, or even patches (series of
different changes that depend upon each other) are well reviewed and if CI is
hooked up (as is the case with ONAP) that _no_ single change when merged should
cause a break (thought without running a CI system like Zuul we can't guarantee
that any particular merge order will _not_ break)."
Without branching/merging, I think the internal AT&T team for AAF would have to
create some sort of shadow project. Is that what other teams do? By shadow
project, I mean that a team would run its own clone, internally or git hub,
where branching/merging is permitted. Then, dump them all up to ONAP's repo
when master is open to contribution. This requires more effort (mostly
housekeeping) and adds risk. How has other teams dealt with these?
Shadow build environment: Does the internal team need to replicate
ONAP's CI/CD Jenkins jobs? Probably. If not, ONAP specific scans would not
occur until the internal changes are dumped up to ONAP's repo.
Diverging release roadmap: If AT&T team wants to build a release use
between ONAP releases, it would be for internal use only; the team would have
to rename the java artifacts to prevent a name clash with ONAP artifacts.
Shadow issue tracking: The AT&T team would track these changes in
corporate internal jira, not ONAP's, and maintains some convention to map the
issue keys.
Shadow static scans: The internal team would have to run a different
CI/CD environment; the team would not be able to take advantage of automatic
scans built into ONAP's job builder.
Divergence due to refactoring: Refactoring to remove technical debt
can be more risky because these changes would not immediately merge to ONAP's
repo.
Diverging interests: Features and fixes driven solely by stakeholders
within AT&T may not be contributed to ONAP at all.
Thanks for any help. I'm hoping to fit into ONAP's process, but I'm also
groping to understand it.
John
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
Andrew Grimberg
Sent: Friday, April 17, 2020 4:48 PM
To: FRANEY, JOHN J <[email protected]>; [email protected];
[email protected]; [email protected]
Subject: Re: [onap-discuss] onap git flow convention?
On 2020-04-17 11:28, FRANEY, JOHN J wrote:
> Thanks Andrew,
>
> I doubt that I am understanding correctly. Git was designed specifically
> around quick efficient frequent merging. Really. Easy merging is the
> primary goal of git's design.
>
> And gerrit disallows merges?
>
> sad. ☹ (Isn't distributed software development difficult enough?)
Our configuration (and the default configuration of Gerrit) disallow merge
commit changes to be proposed. It's something that can be enabled but it breaks
the workflow that Gerrit is striving for in that a single change, or even
patches (series of different changes that depend upon each other) are well
reviewed and if CI is hooked up (as is the case with ONAP) that _no_ single
change when merged should cause a break (thought without running a CI system
like Zuul we can't guarantee that any particular merge order will _not_ break).
So, what I'm saying is this:
You, me, anyone, cannot propose a change that consists of a merge of changes.
What you can propose is a single change, or series of changes that depend on
each other that when all validation has passed and a committer 'submits' the
change may either be a fast-forward merge, or a standard merge.
Basically, we disallow you to push something that is specifically a merge
commit object.
-Andy-
--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20744): https://lists.onap.org/g/onap-discuss/message/20744
Mute This Topic: https://lists.onap.org/mt/73054581/21656
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
