search

ucberkeley / bce

Berkeley Common Environment provides a common Linux computational environment for classwork and research.
Apache License 2.0
13 stars 6 forks source link

Shift git workflow to focus on master branch #50

Closed ck37 closed 8 years ago

ck37 commented 9 years ago

I think focusing on the master branch for bug fixes and new features would be a better model git workflow for this project, particularly given that the modification velocity is somewhat sporadic. It doesn't seem to me that the overhead of a separate dev branch is beneficial for the circumstances of this project. Under the current policy "dev" is the useful branch and "master" is generally out of date, plus there isn't a big userbase that is building from master for whom we need to carefully guard against the minor chance of bugs creeping in.

Right now master is 72 commits behind dev and master hasn't been updated in 6 months. I would argue that under the BCE use case (single digit usage of the source repo, 99% of users are only downloading the generated .ovas or using the AMIs) there is not really a benefit to holding "production" from all of the improvements that have been made since January.

Here are a few related articles that I reviewed as food for thought:

  1. http://blog.endpoint.com/2014/05/git-workflows-that-work.html
  2. http://www.barryodonovan.com/2012/07/03/two-git-branching-models
  3. http://nvie.com/posts/a-successful-git-branching-model/

As one proof of concept, Caret is the main machine learning framework in R that does this with a much larger source userbase: https://github.com/topepo/caret

So I would like to put in a vote to remove the "dev" branch approach in favor of simply merging directly to master.

ryanlovett commented 9 years ago

I agree with you. @aculich and I configured the repo this way with more activity in mind I think it is overdesigned for the amount of activity we have. (though the degree to which dev trails master is just my being lazy)

Aaron, thoughts?

Ryan

On Wed, Jul 15, 2015 at 9:27 PM, Chris Kennedy notifications@github.com wrote:

I think focusing on the master branch for bug fixes and new features would be a better model git workflow for this project, particularly given that the modification velocity is somewhat sporadic. It doesn't seem to me that the overhead of a separate dev branch is beneficial for the circumstances of this project. Under the current policy "dev" is the useful branch and "master" is generally out of date, plus there isn't a big userbase that is building from master for whom we need to carefully guard against the minor chance of bugs creeping in.

Right now master is 72 commits behind dev and master hasn't been updated in 6 months. I would argue that under the BCE use case (single digit usage of the source repo, 99% of users are only downloading the generated .ovas or using the AMIs) there is not really a benefit to holding "production" from all of the improvements that have been made since January.

Here are a few related articles that I reviewed as food for thought:

  1. http://blog.endpoint.com/2014/05/git-workflows-that-work.html
  2. http://www.barryodonovan.com/2012/07/03/two-git-branching-models
  3. http://nvie.com/posts/a-successful-git-branching-model/

As one proof of concept, Caret is the main machine learning framework in R that does this with a much larger source userbase: https://github.com/topepo/caret

So I would like to put in a vote to remove the "dev" branch approach in favor of simply merging directly to master.

— Reply to this email directly or view it on GitHub https://github.com/ucberkeley/bce/issues/50.

aculich commented 9 years ago

I'm in favor of simplifications that make managing it easier.

aculich commented 9 years ago

A quote I like from the first article is:

Complicated workflows drive people crazy. Make it simple. Review your workflow and ask how you can simplify it. In actively making things more simple, you will also make them easier to understand and work with as well as easier for others to adopt and maintain.

A master-only workflow is fine with me for the amount of activity the repo has.

ck37 commented 9 years ago

In the meantime at least I've set "dev" as our default branch on github, which I think will be helpful.

paciorek commented 8 years ago

Ok, I merged dev onto master and made master the default branch.