use development branches for larger features and changes

[wholmgren]

Is the pvlib community interested in using development branches for larger features and changes? The idea is to get relatively large proposals in the hands of more people before they're merged. For example, #124 is a large feature addition and #151 breaks the existing API, so they require a 0.x version change to merge instead of only a 0.x.y change. More importantly, I am reluctant to merge large changes without more significant user feedback.

But critical user feedback is harder to get if it requires navigating the git maze. If you're comfortable using git then it's very easy (and powerful) to checkout another user's PR to try for yourself, but if you're newish to git and using GitHub Desktop or similar then it's somewhere between a mystery and impossible to do that. I think (hope?) that newish users of git and GitHub Desktop can switch branches of a single remote repository without too much trouble.

How would this work in practice? All features would still start out as PRs against master. Depending on the scope, we may decide to add it as a new branch once the code is useable. One of the maintainers would have to complete that step. The original PR can then be closed, and a new PR can be opened from the development branch to the master branch. The original developer can still submit his/her own PRs against the development branch. The maintainers can quickly merge these PRs with abandon since they don't impact master. Once everything is good, the development branch can be merged into master and deleted.

Either way, I'm planning to push a development branch for the forecasting/expanded-io-module PR tomorrow because I think it will make accessing the code/documentation for my PVSC paper/poster slightly less confusing.

Thoughts?

@jforbess and @cwhanse might have some perspective on this.

[jforbess]

I think the use case you're citing now will be a good example for others to
try. I think I would be more likely to use development branches if they
existed, rather than pulling other's PRs, which isn't really something I
have thought about doing, even with this PR #151 now.

On Sat, May 21, 2016 at 8:23 PM, Will Holmgren notifications@github.com
wrote:

Is the pvlib community interested in using development branches for larger
features and changes? The idea is to get relatively large proposals in the
hands of more people before they're merged. For example, #124
#124 is a large feature
addition and #151 #151 breaks
the existing API, so they require a 0.x version change to merge instead of
only a 0.x.y change. More importantly, I am reluctant to merge large
changes without more significant user feedback.

But critical user feedback is harder to get if it requires navigating the
git maze. If you're comfortable using git then it's very easy (and
powerful) to checkout another user's PR to try for yourself, but if you're
newish to git and using GitHub Desktop or similar then it's somewhere
between a mystery and impossible to do that. I think (hope?) that newish
users of git and GitHub Desktop can switch branches of a single remote
repository without too much trouble.

How would this work in practice? All features would still start out as PRs
against master. Depending on the scope, we may decide to add it as a new
branch once the code is useable. One of the maintainers would have to
complete that step. The original PR can then be closed, and a new PR can be
opened from the development branch to the master branch. The original
developer can still submit his/her own PRs against the development branch.
The maintainers can quickly merge these PRs with abandon since they don't
impact master. Once everything is good, the development branch can be
merged into master and deleted.

Either way, I'm planning to push a development branch for the
forecasting/expanded-io-module PR tomorrow because I think it will make
accessing the code/documentation for my PVSC paper/poster slightly less
confusing.

Thoughts?

@jforbess https://github.com/jforbess and @cwhanse
https://github.com/cwhanse might have some perspective on this.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#178

[wholmgren]

I added development branches and new pull requests for the ModelChain refactor (PR #179) and forecast module (PR #180). We'll see how it goes.