Discuss a two-branch workflow about lcm

[ikalash]

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.

[gahansen]

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.

[ibaned]

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:

1. Remove stale branches
2. 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
3. Set up a "gatekeeper" dashboard, which will determine whether a particular commit is considered "stable"
4. 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 ?

[ibaned]

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.

[rppawlo]

You can change the default branch on github, doesn't have to be "master".

https://help.github.com/articles/setting-the-default-branch/

[bartgol]

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.

[lxmota]

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.