-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rethink CCPP framework development cycle and branch structure #553
Comments
I like this. The development branch should be named |
This all seems sensible to me, but isn't the governance of development outside of "main" none of our business? |
After further discussion at the framework meeting (see Meeting Minutes for details), we have three options:
In an effort to keep track of people's ideas, I've started a pro/con chart here. I have populated it with themes and ideas I pulled from our meeting, but feel free to edit with your thoughts. I will post a screenshot of the final list here in this issue when we're "done" for record-keeping; here's what it looks like now: |
@peverwhee Thanks again for listing this all out and organizing the pros and cons. After some time to digest the topic, I've come up with some (mildly rambly) thoughts: Off the bat, I am leaning towards solution 2 (separate branches for each host model). Specifically, a modified proposition that would use forked repositories rather than simple branches within the main repository: this would bring ccpp-framework more in line with how ccpp-physics is handled, and would allow CESM/SIMA and other individual projects to work at their own development pace and only take contributions from the main branch/repository when they are ready. My reason for wanting forks is that this will allow for issues and PRs specific to each dycore to be appropriately separated so that A. Issues and PRs will be seen more easily by the people most able to fix them, and B. The main repository will remain less cluttered and easier to maintain. In order for this to actually work, we would need buy-in from all groups maintaining forks that
As a counterpoint to the testing requirements from the main branch, groups with forks would also have the right to insist on any tests they require being run on all development to the main branch. In fact, the more automated testing at more steps, the better! As for what kind of cadence to merge changes back into the main repository, I don't really know what makes sense. |
Updated pro/con list with contributions from @mkavulich |
Hi @mkavulich et al., after discussion from the group here at NCAR/CGD, we just wanted to share our overall thoughts:
Given this, assuming there is no way to significantly speed up testing, we are leaning towards having a shared development branch. Of course we are always happy to discuss this further if folks still have concerns. Thanks! |
Summary
Now that feature/capgen has been merged into main, we have the opportunity (and perhaps necessity) to change the development cycle to:
NCAR Wish List
Proposal
“Regular” workflow:
The text was updated successfully, but these errors were encountered: