Usually sdk's between components are branched and released earlier so that they can be referenced like SDC and portal so that there is either a non-snapshot version that is available for builds or a non-snapshot container for oom references.
Brain . -----Original Message----- From: FRANEY, JOHN J <[email protected]> Sent: Monday, April 20, 2020 2:40 PM To: FREEMAN, BRIAN D <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: RE: [onap-discuss] onap git flow convention? Brian, Thank you. I didn't know this: the project team, not LF, will create the ONAP release branch and Jenkins jobs. I'll look for wiki entry on how to do this. I assume it’s a privileged task for the PTL. Question: How about branches for component releases? Are these permitted? Are they common? For example, AAF could release its client library between Frankfurt and Guilin releases and then create a release branch for it. John -----Original Message----- From: FREEMAN, BRIAN D <[email protected]> Sent: Monday, April 20, 2020 12:36 PM To: [email protected]; FRANEY, JOHN J <[email protected]>; [email protected]; [email protected]; [email protected] Subject: RE: [onap-discuss] onap git flow convention? Some suggestions below on how we do it in other repositories. Brian -----Original Message----- From: [email protected] <[email protected]> On Behalf Of FRANEY, JOHN J Sent: Monday, April 20, 2020 12:20 PM To: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [onap-discuss] onap git flow convention? *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Sylvain, Thank you, and Andrew and Ittay as well. I have to learn how ONAP tooling works, and this discussion helps. 1) I want to contribute to and release a new version of AAF now, but these changes and release will NOT be included into Frankfurt. Creat a Frankfurt branch and that would be the branch that you submit fixes to for frankfurt Create Jenkins jobs for the Frankfurt branch verify/merge/docker similar to what you probably have for elalto Master branch then becomes what will be used for guillan (and at some point you do the same - cut a guillan from master so that guillan is stable and master moves to base for "h" release. 2) I want to support multiple releases at the same time. Multiple versions are used by multiple stakeholders at the same time. Each branch is separate You cherry pick from master to release-branch (e.g., Frankfurt) when it makes sense like a bug fix in something that is common for master and a release-branch Please how? Thank you. John -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Sylvain Desbureaux via lists.onap.org Sent: Monday, April 20, 2020 2:53 AM To: FRANEY, JOHN J <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Re: [onap-discuss] onap git flow convention? Hello John, First, you need to know that I'm not a great lover of gerrit (and Jenkins), as these legacy systems are bringing a lot of barriers. But, LF IT seems to think they're more interesting than gitlab or github/github actions so we have (unfortunately) to live with them. Before working for ONAP, I did too use the "git flow" paradigm (https://urldefense.proofpoint.com/v2/url?u=https-3A__buddy.works_blog_5-2Dtypes-2Dof-2Dgit-2Dworkflows-23gitflow&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=kPKOKzg4Z4tIa1Jcwm6xxA&m=nNTUlmU0EJk4nct7Om4OdYqRw69RjfXty0f_H6XaSn0&s=PvBtYPa8ED2hRcYx1FJnkPNGVxRFXf5xUlTeiPhTs7M&e= ). So, Gerrit doesn't work with git flow as we are not allowed to create branches / forks + merge request but rather we have to send "reviews". A review is actually one (and only one) commit where all your changes are (think the stash of all your commits from a branch). So, instead of having one branch with several commits that will eventually (most of the time, for better readability) be stashed, you directly work on the "final" commit. The main difference are: * you don't have a "develop" branch but I'm not sure at the end it's a good practice * releases are not tag but branch (and tags), again this is a different view but it's not that bad This gives pros and cons: pros: * only one commit, making git history simple * no commit with message like "typo fix", "oops", "reverting again" and so on cons: * To work with several features in parallel, it's up to you to use the workflow locally you want. I personally create a branch per feature but any solution should work * if your push by mistake a second commit, it will become a new merge request (with relationship but still) But, at the end, it's very similar to Pull Request / Merge Request we can have on github/gitlab Regards, Sylvain ________________________________________ De : FRANEY, JOHN J [[email protected]] Envoyé : dimanche 19 avril 2020 19:33 À : [email protected]; [email protected]; DESBUREAUX Sylvain TGI/OLN; [email protected] Objet : RE: [onap-discuss] onap git flow convention? 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 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20767): https://lists.onap.org/g/onap-discuss/message/20767 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]] -=-=-=-=-=-=-=-=-=-=-=-
