Comments (7)
I agree with this comment, however, I ask that the epetra branch of Albany be retained. We still use this branch for some production FELIX runs, due to it being faster.
from lcm.
I also agree that it would be nice to clean up all stale branches that we can.
I'd like to discuss the develop/master branch work flow more before settling on this. I worry that this will make repository access to new users significantly more difficult; this approach is a step up in complexity that will increase the entry barrier for some folks. Secondly, this adds significant complexity in everyone's workflow - are we confident that we get a good return on this investment?
As an alternative, I'd suggest we consider cleaning up our tests and dashboards more diligently in the short term, and perhaps be more proactive in addressing dashboard issues that appear as a result of new commits and Trilinos changes. Perhaps we could consider occasionally "tagging" the repo (along with noting the corresponding Trilinos HEAD commit sha) that generates a clean dashboard?
In my experience, instability in the current Albany build can be (often is) due to changes in the upstream dependencies - changing our workflow to a develop/master one will not address these cases.
from lcm.
Stale branches, absolutely.
I can understand the concerns about workflow complexity, we want to add nearly zero overhead compared to how people work now. In my experience with master/develop codes, the main overhead has only been switching to the develop branch, because Git by default checks out the master branch.
The way I employ a master branch is essentially just as an implementation of this "tagging" of stable versions that have passed a series of checks. In PUMI, this "tagging" (merging to master) is done automatically by the nightly dashboard system when the develop branch is all green. In Omega_h, I manually run GCC, Clang, and NVCC tests and manually assign a new version number.
I'm guessing version numbers matter less for Albany, because it is not primarily a library. As such, an automated tagging merge based on the dashboards may make more sense. Since it is based on the dashboards, and for the other reasons @gahansen mentioned, I think this this order of operations is best:
- Remove stale branches
- Clean up the current dashboards: we should aim for all non-exotic entries to be all green. I'll kick off a series of issues to get us to this point
- Set up a "gatekeeper" dashboard, which will determine whether a particular commit is considered "stable"
- Use a branch to keep track of stable versions
As for step (4), there are two ways we could do this:
- "master" is the development branch, and we create a branch called "stable" that is automatically updated by the gatekeeper dashboard
- "master" is the stable branch, only touched by the gatekeeper, and we create a "develop" branch that all developers push to.
The main difference is on whom we put the burden of selecting a non-master branch: the developers, or the users who want stability ?
from lcm.
I've separated this issue into two, sandialabs/Albany#60 tracks what we all agreed on which is stale branch removal. Since discussion started here, I'd like this issue to focus on the idea of a two-branch workflow and what people want to do there. Hopefully this is okay with @lxmota.
from lcm.
You can change the default branch on github, doesn't have to be "master".
https://help.github.com/articles/setting-the-default-branch/
from lcm.
I agree with pretty much everything you guys said.
I have myself at least one stale branch on the repo, sideset_equations, which I'm cleaning up to prepare for a pull request, but I had to do some work with the merging, so I ended up creating a new branch (sideset_equations_cleanup).
As for the master+stable/develop dichotomy, I'm for master+develop. It appears to me to be a much more common name, that new users/developers can easily recognize and use correctly. It would probably be roughly the same, it's just a matter of being comfortable with the pattern.
from lcm.
The reason I propose a two-branch workflow is that we have LCM users (by that I mean users that run the code and do not do any development) that periodically check out the code to run simulations. In the past these users have been burned by checking out from the master branch and finding out that it does not compile.
That was the reason I created this wiki page:
https://github.com/gahansen/Albany/wiki/LCM-Status:-Last-known-commits-that-work
Yes, I agree with @gahansen that a two-branch workflow will add increased complexity for developers. But the LCM project has a mandate to make it easier for non-developers to use the code, and the instability of the master branch has been an issue that has been pointed out as making Albany difficult to use.
@ibaned I personally prefer the master/develop approach as they do in Trilinos. But perhaps to make it less intrusive, master/stable works best.
As @gahansen says, we could also consider tagging stable releases, and keep only the master branch.
I'm open to all these possibilities as long as there is a mechanism for non-developers to check out a stable copy of the repo.
from lcm.
Related Issues (20)
- Revive CEE nightly test HOT 4
- Update Albany-LCM wiki homepages HOT 1
- CDash reporting errors when build completes HOT 12
- Failing tests in nightly LCM builds HOT 1
- Failing builds due to stk changes
- Failing MiniErosion serial tests HOT 2
- TrilinosConfig.cmake not created in nightly Trilinos builds on algol and proxima HOT 5
- ACE cleanup for ACI/NH: make maximum displacement an input parameter for erosion criteria HOT 3
- ACE cleanup for ACI/NH: see if repetition of Adaptation/Erosion parameter sublist can be moved to coupled*yaml file? HOT 1
- ACE cleanups for ACI/NH: put in throw if one is trying to use Tempus mechanical solver with erosion HOT 1
- ACE cleanups for ACI/NH: extend Piro mechanical solver in ACE to work w/o Erosion
- ACE: add throw when thermal conductivity parameters are not specified correctly in yaml file HOT 1
- ACE cleanups for ACI/NH: different convergence behavior when running ACE problem w/o Erosion with Tempus vs. Piro HOT 1
- Newmark parameters don't appear to be used in Tempus time-stepper
- ACI/NH: test thermo-mechanical ACE problem with implicit thermal stepper HOT 5
- ACI/NH: rework code to add snow contribution HOT 1
- Rebaseline failing ACE tests in main VOTD
- Most of LCM nightlies began failing on 2/7 HOT 8
- Remove ACEice and ACEpermafrost classes as these are obsolete/not used HOT 3
- Rework LCM to not use deprecated STK code HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lcm.