search

NOAA-EMC / NCEPLIBS

Top level repo containing submodules for NCEPLIBS and associated dependencies for superproject builds
Other
42 stars 18 forks source link

Use of gerrit intentional in two submodules on the master branch? #69

Closed edwardhartnett closed 4 years ago

edwardhartnett commented 4 years ago

In the branch ufs-v1.0.0 in .gitmodules you have:

[submodule "NCEPLIBS-crtm"]
    path = NCEPLIBS-crtm
    url = https://github.com/NOAA-EMC/EMC_crtm
    branch = release/public-v1
[submodule "NCEPLIBS-post"]
    path = NCEPLIBS-post
    url = https://github.com/NOAA-EMC/EMC_post
    branch = release/public-v1

In the master branch you have:

[submodule "NCEPLIBS-crtm"]
    path = NCEPLIBS-crtm
    url = gerrit:EMC_crtm
    branch = spack-build
[submodule "NCEPLIBS-post"]
    path = NCEPLIBS-post
    url = gerrit:EMC_post
    branch = spack-build

Is the use of gerrit in the case of these two libraries intentional?

It is making it difficult to set up CI on the master branch...

kgerheiser commented 4 years ago

Don't try to use the master branch. It is not maintained and is not meant to be a usable state of the project. This is how the NCEPLIBS umbrella build looked 6 months ago before we moved to the release/public-v1 branch when we were first starting and it hasn't been touched since.

edwardhartnett commented 4 years ago

Let me re-phrase the question: if I submit a PR to bring master up to date with release/public-v1, will you merge it to master?

I am trying to set up a demonstration of using travis continuous integration, and it would be helpful if master actually represented the latest working build, which is public-v1.

Then, development can continue on master, preparing for public-v2, and PRs against master will be automatically tested for correctness by Travis...

kgerheiser commented 4 years ago

I'm not sure what our strategy here is.

I agree that master should not be in its current state while being our default branch. I'm not against bringing master up-to-date with release/public-v1 if to just have it be something sane, but as a long term solution I think the release branch should be our master branch with a develop branch to bring changes into there.

Thoughts @climbfuji, @mark-a-potts?

edwardhartnett commented 4 years ago

The general practice is not to have the release branch be the master branch, but a branch from the master branch.

The point of a develop branch is that master stays somewhat more stable, but still ahead of the most recent release, and develop changes every day with multiple contributors. That does not seem to be the level of activity I see on this repo.

However, the first step is to bring master up to date, and buildable.

kgerheiser commented 4 years ago

Sure, the more I think about it the more that seems like a better idea.

edwardhartnett commented 4 years ago

Awesome. I have submitted a PR.

edwardhartnett commented 4 years ago

This was fixed in PR #70