Brainstorming on Feature Branches

[bgrant0607]

Feature branches have been discussed as a possible way to stabilize both the master branch and releases.

http://nvie.com/posts/a-successful-git-branching-model/
https://github.com/nvie/gitflow
https://www.atlassian.com/git/tutorials/comparing-workflows
https://dev.acquia.com/blog/pragmatic-guide-branch-feature-git-branching-strategy
https://news.ycombinator.com/item?id=11190310

This issue is intended to be a home for discussion on that topic.

cc @idvoretskyi @thockin @jagosan

[jagosan]

The branching model in Brian's first link, generally known as gitflow, is what I've seen work best.

Kubernetes currently runs on a quarterly release cadence. The he impact of this is that there is tremendous pressure to hit the release date. Corporate performance evaluations and personal satisfaction can hinge on hitting the deadline; the cost of missing the release because something isn't quite done is 3 months - too long for most. Worse, for PMs or organizations, if their feature is not prioritized for inclusion in the next release, their feature is at-best 6 months out (the release date for the following release). So multiple, large-scale features are merged to master in a very short period of time, some of which are not complete and may not be fully tested. As more contributors enter the fray, the interaction of various, possibly interdependent, features exacerbates the issue. It's virtually impossible for the first release to be fully functional, and it anecdotally it sounds like the 1.x.0 releases have generally had issues.

The other major issue is that master is continuously changing, so devs can become skittish about when to merge from master into local repos for fear that some partially-complete feature will stomp on their current work. The longer they wait, though, the worse it becomes. Most projects hit issues much earlier than kubernetes. I think it is a testament to the caliber and dedication of the engineers on the project that so much still gets done, and that releases have worked as well as they have for the past year or so. That said, I think it could be improved by adopting a branching strategy more conducive to the project complexities.

Feature branches help. Whatever branching model is used, keeping collaboration on large features in a separate branch until relatively well baked is helpful for anyone who isn't working on that feature - life can continue. The downside is that there is some more merging from master into the feature branch before then merging back to master... but it's generally a good thing. But feature branches on their own is not a complete answer.

The gitflow approach espouses a 'develop' branch which behaves the way it appears kubernetes master branch works today: code that compiles and is correct, but perhaps not complete is checked in frequently. In contrast, in gitflow the commitment is that master, always, always works; features are fully baked and fully tested. Culture or rules often restrict who can merge to master.

A note about feature branches: There is often more emphasis on feature branches than I think is necessary or useful. While trivial and near trivial changes can be committed directly to develop, feature branches can be extremely small and may be created just for local experimentation, or they can be much larger affairs, with contributions by multiple teams. The main benefit I've seen is that it keeps half-baked ideas from being checked into develop (or master) just for purposes of collaboration or remote backup.

release branches are also suggested in gitflow. This is often used as a finer grained mechanism for managing the time from feature complete to production-ready. New development can continue along as before in the develop branch (they'll catch the next train) while bug fixes are applied directly to the release branch. When the release branch is stable, it gets merged back to master.

[calebamiles]

cc: @philips

[thockin]

I don't understand the importance of keeping master as a pseudo-release line. I would expect the desire for "code for the most recent release, but I don't care which" to be minimal. If you want code for a release, don't you want a particular release? Having development on a branch other than "master" seems like it would cause a lot of bad PRs. In some sense we have feature branches, in the form of all of our particular personal forks, but we could encourage more use of shared feature branches. In truth we have a vast proportion of single-person efforts, so it is somewhat moot. The biggest problem I see is that too many efforts touch the same files, causing huge pain. The more detached you are from master, the worse that can get. Not even counting generated code. On Apr 21, 2017 4:22 PM, "Jago Macleod" <notifications@github.com> wrote: The branching model in Brian's first link, generally known as gitflow, is what I've seen work best. Kubernetes currently runs on a quarterly release cadence. The he impact of this is that there is tremendous pressure to hit the release date. Corporate performance evaluations and personal satisfaction can hinge on hitting the deadline; the cost of missing the release because something isn't quite done is 3 months - too long for most. Worse, for PMs or organizations, if their feature is not prioritized for inclusion in the next release, their feature is at-best 6 months out (the release date for the following release). So multiple, large-scale features are merged to master in a very short period of time, some of which are not complete and may not be fully tested. As more contributors enter the fray, the interaction of various, possibly interdependent, features exacerbates the issue. It's virtually impossible for the first release to be fully functional, and it anecdotally it sounds like the 1.x.0 releases have generally had issues. The other major issue is that master is continuously changing, so devs can become skittish about when to merge from master into local repos for fear that some partially-complete feature will stomp on their current work. The longer they wait, though, the worse it becomes. Most projects hit issues much earlier than kubernetes. I think it is a testament to the caliber and dedication of the engineers on the project that so much still gets done, and that releases have worked as well as they have for the past year or so. That said, I think it could be improved by adopting a branching strategy more conducive to the project complexities. Feature branches help. Whatever branching model is used, keeping collaboration on large features in a separate branch until relatively well baked is helpful for anyone who isn't working on that feature - life can continue. The downside is that there is some more merging from master into the feature branch before then merging back to master... but it's generally a good thing. But feature branches on their own is not a complete answer. The gitflow approach espouses a 'develop' branch which behaves the way it appears kubernetes master branch works today: code that compiles and is correct, but perhaps not complete is checked in frequently. In contrast, in gitflow the commitment is that master, always, always works; features are fully baked and fully tested. Culture or rules often restrict who can merge to master. A note about feature branches: There is often more emphasis on feature branches than I think is necessary or useful. While trivial and near trivial changes can be committed directly to develop, feature branches can be extremely small and may be created just for local experimentation, or they can be much larger affairs, with contributions by multiple teams. The main benefit I've seen is that it keeps half-baked ideas from being checked into develop (or master) just for purposes of collaboration or remote backup. release branches are also suggested in gitflow. This is often used as a finer grained mechanism for managing the time from feature complete to production-ready. New development can continue along as before in the develop branch (they'll catch the next train) while bug fixes are applied directly to the release branch. When the release branch is stable, it gets merged back to master. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#566 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVBSIXYWNAjdv8SdVJ-xD7kiNP5Egks5ryTo0gaJpZM4NE3t2> .

[bgrant0607]

@thockin Development in a single branch means that there may never be a releasable branch.

I think the choices are repos or branches/forks. No new major feature development should happen in the kubernetes repo directly. We need to be able to gate half-baked, broken, untested, undocumented code.

[bgrant0607]

How the Linux Kernel uses forks and branches:
http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html

[mattfarina]

@bgrant0607 how long would you expect feature branches to live for? If they are long lived it could be more difficult to merge the changes in.

I've been a fan of gitflow and github flow having used them quite a bit. The danger has to do with development of long lived branches. Sometimes it's easier to put early features behind flags and iterate on a feature via multiple feature branches.

[bgrant0607]

@mattfarina How long branches would live is TBD. I understand that branches increase the burden on contributors, but that is a necessary tradeoff at this point. I think the alternative is to apply a lot more rigor to every code review, require docs and tests to be written before the code, and other process changes that would also increase the burden on contributors, just in other ways.

I have seen feature flags used to good effect in other contexts, also, but it isn't clear to me how we could achieve the necessary level of rigor to make them work on this project. At minimum, before that approach would be viable, we'd need to radically improve the quality and coverage of our testing.

[idvoretskyi]

How long branches would live is TBD.

@mattfarina @bgrant0607 I'd suggest if feature branch lifecycle will be equal to the feature lifecycle itself - since the early design proposal stage until GA.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale