fix function name change from nemo

[gshennvm]

What does this PR do ?

Add a one line overview of what this PR aims to accomplish.

change function name because of NeMo PR

[gshennvm]

potential issue with this PR is that it will make #47 not work unless that container pins nemo main

[odelalleau]

potential issue with this PR is that it will make #47 not work unless that container pins nemo main

We need to be clear on expectations. Here are my thoughts:

• Users need to be able to easily setup an official version by following instructions in the main branch's README.md
• Developers need to be able to easily setup the main branch's latest code following instructions in the main branch's CONTRIBUTING.md

I haven't looked closely at #47 yet and I'm not sure whether it's meant to serve users, developers, or both.

My main concern with merging this PR is it may prevent devs from using the latest main branch if we don't provide setup instructions somewhere. Just grabbing latest NeMo's main may or may not work. I think CONTRIBUTING.md should document the development setup, and we should keep it updated. Do you have other ideas on how to handle this?

[gshennvm]

potential issue with this PR is that it will make #47 not work unless that container pins nemo main

We need to be clear on expectations. Here are my thoughts:

• Users need to be able to easily setup an official version by following instructions in the main branch's README.md
• Developers need to be able to easily setup the main branch's latest code following instructions in the main branch's CONTRIBUTING.md

I haven't looked closely at #47 yet and I'm not sure whether it's meant to serve users, developers, or both.

My main concern with merging this PR is it may prevent devs from using the latest main branch if we don't provide setup instructions somewhere. Just grabbing latest NeMo's main may or may not work. I think CONTRIBUTING.md should document the development setup, and we should keep it updated. Do you have other ideas on how to handle this?

Agree with the above concerns. Just to summarize the concrete plan(let me know if you think we can do this better!).

code dev flow

• there will be 2 working branches: main and CI on aligner. Main will pin nemo version and only upgrade when nemo releases something stable which is every 2 months. The CI branch will track nemo main. Before every aligner release we will do a diff on CI branch and main and pick the CI branch(which i suspect have less changes) onto nemo aligner main.
• we guarantee that users can build their own container using the dockerfile and nemo-aligner main will work with the dockerfile in Public Dockerfile #47. This dockerfile will then be upgraded every other month.

PRs

• for stability PRs will be submitted to nemo-aligner main that uses a stale nemo version. But it is very important for the CI to be setup on any feature additions because when we cherry pick from CI -> main we need those tests to guard for convergence issues.

documentation

• agree with your suggestion. README will install stable nemo with our dockerfile. CONTRIBUTING will be dev setup.

How do these sound?

[odelalleau]

How do these sound?

Sounds good to me! Just a couple of questions to be sure I got the full picture:

1. I assume bringing PRs from main to ci will be automated, but what will happen in case of conflict?
2. Where are CI results reported btw? (in other words, if a PR on main breaks the CI, where do we see it?)

[gshennvm]

How do these sound?

Sounds good to me! Just a couple of questions to be sure I got the full picture:

1. I assume bringing PRs from main to ci will be automated, but what will happen in case of conflict?
2. Where are CI results reported btw? (in other words, if a PR on main breaks the CI, where do we see it?)

1. In case of conflict I think we need to find the contributor for resolution. Normally NeMo changes all relate to renaming things and changing some implementation of core functions. I don't expect there to be too many conflicts.
2. I'll send you the info for the CI

[odelalleau]

• In case of conflict I think we need to find the contributor for resolution. Normally NeMo changes all relate to renaming things and changing some implementation of core functions. I don't expect there to be too many conflicts.

Yeah me neither, I just wanted to understand the process. I'm not sure how this automation would work, and how someone would fix the conflicts when they occur. As long as you're confident it'll work smoothly that's good for me, it's just a bit of a grey area right now (for me).

[gshennvm]

• In case of conflict I think we need to find the contributor for resolution. Normally NeMo changes all relate to renaming things and changing some implementation of core functions. I don't expect there to be too many conflicts.

Yeah me neither, I just wanted to understand the process. I'm not sure how this automation would work, and how someone would fix the conflicts when they occur. As long as you're confident it'll work smoothly that's good for me, it's just a bit of a grey area right now (for me).

Yeah.. I need to look more into automating this. For the time being I need to do it manually so things don't randomly break.

It's also a bit of a grey area for me... But I guess this allows us to work on a stable nemo version so maybe it's worth seeing how it'll go

[gshennvm]

I've pointed this MR to dev which will be the branch we run nightly CI with nemo main on, please let me know what you think.

[odelalleau]

I've pointed this MR to dev which will be the branch we run nightly CI with nemo main on, please let me know what you think.

I think this should be good!