Encouraging new development in the develop branch

[favba]

Folks at NCAR follow the git-flow development workflow for MPAS (more info on that here: https://nvie.com/posts/a-successful-git-branching-model/).

In this workflow hardly any new code development is done on top of the master branch directly.
The code development happens on the develop branch. Once they feel the need to make those changes official they just merge the development branch into master and bump the version number.

I've created a develop branch for us that has our own modifications and I'm also periodically merging with NCAR's develop branch. So it has both NCAR's and our latest changes.

Most of our latest modification to the code weren't in the MPAS source code per se, but on adding new helper and post-processing scripts. This kind of modification doesn't lead to any merge conflict with modifications made by NCAR so it doesn't matter if they are done in the master branch or in the development branch.

But once we start working with actual MPAS source code then I think it is absolutely necessary for us to do it in the develop branch, otherwise it will be very hard to incorporate into MPAS-BR any modification done by NCAR in the original branch.

What do you think @pedrospeixoto ? For MONAN we might want to eventually diverge from NCAR's code and then we don't have to worry about that anymore, but at this stage I think it is worth trying to keep our code up-to-date with theirs.

[pedrospeixoto]

I totally agree. At the moment we should have a clean version of MPAS 8.0 + pre and post-processing tools and docs in master, only. I have this bad habit, but I should behave myself and follow better development workflows.... I am thinking about setting that only pull requests can change master, as suggested by @guilherme L. Torres Mendonca ***@***.***> Is this ok, @Danilo Couto de Souza ***@***.***> ? You are at the moment an important user, so this may affect you. I suggest having your work on a branch and then using pull requests to contribute the important pre/pos processing things you have been doing. ok? Please confirm so that we can move forward. Prof. Dr. Pedro da Silva Peixoto Associate Professor Applied Mathematics University of São Paulo (USP <http://www.usp.br/>) www.ime.usp.br/~pedrosp Em ter., 31 de out. de 2023 às 11:48, Felipe A. V. de Bragança Alves < ***@***.***> escreveu:

…

Folks at NCAR follow the git-flow development workflow for MPAS (more info on that here: https://nvie.com/posts/a-successful-git-branching-model/). In this work flow hardly any new code development is done on top of the master branch directly. The code development happens on the develop branch. Once they feel the need to make those changes official they just merge the development branch into master and bump the version number. I've created a develop branch for us that has our own modifications and I'm also periodically merging with NCAR's develop branch. So it has both NCAR's and our latest changes. Most of our latest modification to the code weren't in the MPAS source code per se, but on adding new helper and post-processing scripts. This kind of modification doesn't lead to any merge conflict with modifications made by NCAR so it doesn't matter if they are done in the master branch or in the development branch. But once we start working with actual MPAS source code then I think it is absolutely necessary for us to do it in the develop branch, otherwise it will be very hard to incorporate into MPAS-BR any modification done by NCAR in the original branch. What do you think @pedrospeixoto <https://github.com/pedrospeixoto> ? For MONAN we might want to eventually diverge from NCAR's code and then we don't have to worry about that anymore, but at this stage I think it is worth trying to keep our code up-to-date with theirs. — Reply to this email directly, view it on GitHub <#10>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJRWWNRF6PU7F6IE6JMVUDYCEFUJAVCNFSM6AAAAAA6X2N742VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZVG44TQMJZHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[guilhermeltm]

In particular I feel it might help to have one branch for each new feature/set of features we'd like to add to master, which would then be merged via a PR. Reasons: firstly, for people not involved in the reviewing process this would improve awareness of what is being added to master (the title of the branch/PR would easily convey the message); and secondly, having a single develop branch or even one branch for each team member may lead to PRs with a lot of changes with different purposes, which could then mean long, tiring reviewing processes. Ideally one would like to have short, periodically created PRs with a specific goal. But this is of course only a suggestion, if you feel we are too early in the development stage, I am also fine with not being so strict.

[daniloceano]

@pedrospeixoto @guilhermeltm @favba

First and foremost, I apologize for not strictly adhering to the branch-based workflow for my modifications. I understand the importance of maintaining a clean and organized codebase, and I recognize the challenges that can arise when not following best practices.

Moving forward, I'm committed to working on specific branches for my modifications and ensuring that they align with the development workflow. I appreciate the suggestions and guidance from everyone, and I'll be more diligent in this regard. I believe that by adopting such practices, we can ensure smoother collaborations and better code management.

Thank you for your understanding and patience.