[xwiki-devs] New development strategy
Hi devs, Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy. = Short version: 1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer 2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch. I vote 1C and 2D. = Long version The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out. On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks". A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore). A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub. == Commit/Development-related strategies A. One central repository, one trunk (subversion-like) Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository. B. One central repository, feature branches Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch. B1. Also use specific helper branches Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version. Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it. C. One aggregated repository, pulling from developers Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers. We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request. Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code. == Integration/Release-related strategies Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development. This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone). Short releases from a development branch is inline with agile development, but personally I find it too dangerous. Most big projects always keep the main development at least one branch away from the release branch. One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me). Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well. I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality. The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen. So, here are some possible integration strategies: A. Master development (like now) All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development. B. Feature branches All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough. C. Feature+Development+Release branches All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features. D. Feature+Development+Stable+Release branches This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch. E. Feature+Development+Next+Release This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers. We can also impose windows, like 2-4 weeks for a feature to move into the next branch. We could also make faster releases, skipping milestones. and going to 6 week releases. This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization. But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs. Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers! As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi, I have already said this in another thread, but it seems that this is the place where I would have replied in the first place. Not sure if what you said covers what's written in that post, but I've found this document explain a very interesting branching model: http://nvie.com/posts/a-successful-git-branching-model/ Maybe we could integrate these ideas in what you are proposing. As a side note, I like a lot generating patches as pull requests that are integrated after a code review. -Fabio On Sat, Apr 2, 2011 at 7:31 PM, Sergiu Dumitriu <[email protected]> wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development. This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Sergiu, I've read your mail and I have some quick remarks/questions: 1) Concerning part 1, I like the fact of working on a fork and sending pull requests (solution C), though it seems a bit overkill for committers who "really knows what they are doing". In my particular case I would gladly fork the project in order to have the chance to submit pull requests whenever I think my code needs a review. I think that sending pull requests is only possible if you are working on a fork, so if we want to use github as an effective code-review platform we should always work with forks. The overhead of working with a fork could be worked around by selectively pushing stuff to the main repo. For example, if I am working on something I am confident with, I will push my changes to the main repo (that on https://github.com/xwiki) and then pull them in the fork. If I need a code review, I will push to my fork and issue a pull request. I think this is doable with git, since you can have multiple remotes but I am not an expert so I don't know if this could lead to "hellish" workflows for the developers. 2) Concerning part 2, it's not clear to me what is the lifetime of the branches? Here I am implicitly advertising (again) http://nvie.com/posts/a-successful-git-branching-model/ (I like it a lot because it's simple and cristal clear :)) I think that your point D is very similar to it, but it's not clear to me how the release branch is handled.
From my point of view nobody is allowed to commit in the stable branch, except the release manager when doing a release. When a release starts a release branch is created from the development branch. The release manager prepares the release in that branch and when she's done she merges everything in stable and develop and then delete the release branch. Feature branches appear and disappear as developers work on single features. Every feature branch is deleted after it's merged in develop. develop is the new "SNAPSHOT".
So to sum up, in principle I am +1 for 1C provided that git allows to bypass the pull request by pushing in the main repo from a fork and that this doesn't generate too much hassle for a developer +1 for 2D provided that I have well understood the semantics of these branches :) -Thanks, Fabio On Sat, Apr 2, 2011 at 7:31 PM, Sergiu Dumitriu <[email protected]> wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development. This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 04/04/2011 03:32 PM, Fabio Mancinelli wrote:
Hi Sergiu,
I've read your mail and I have some quick remarks/questions:
1) Concerning part 1, I like the fact of working on a fork and sending pull requests (solution C), though it seems a bit overkill for committers who "really knows what they are doing". In my particular case I would gladly fork the project in order to have the chance to submit pull requests whenever I think my code needs a review. I think that sending pull requests is only possible if you are working on a fork, so if we want to use github as an effective code-review platform we should always work with forks.
No, you can send "pull requests" even on committed code. In that case the request must be manually closed. So even with direct commits it's possible to ask for code reviews via pull requests.
The overhead of working with a fork could be worked around by selectively pushing stuff to the main repo. For example, if I am working on something I am confident with, I will push my changes to the main repo (that on https://github.com/xwiki) and then pull them in the fork. If I need a code review, I will push to my fork and issue a pull request.
I think this is doable with git, since you can have multiple remotes but I am not an expert so I don't know if this could lead to "hellish" workflows for the developers.
Yes, it's doable. "git push" pushes to the "origin" repo. "git push myown" pushes to a remote repo called "myown". What's critical is being careful where each commit goes.
2) Concerning part 2, it's not clear to me what is the lifetime of the branches? Here I am implicitly advertising (again) http://nvie.com/posts/a-successful-git-branching-model/ (I like it a lot because it's simple and cristal clear :))
Yes, I found this one around the time it appeared, and I also liked it a lot. It's similar to D, but from their branch names they use the "master" branch as the most stable one, and not as the development branch. This is useful for forking and checking out "stable" sources, since it will point to the latest release. But personally, as a developer, I prefer to have "master" as the most unstable branch, with the latest code in it. It's all just naming in the end, not very important.
I think that your point D is very similar to it, but it's not clear to me how the release branch is handled. From my point of view nobody is allowed to commit in the stable branch, except the release manager when doing a release. When a release starts a release branch is created from the development branch. The release manager prepares the release in that branch and when she's done she merges everything in stable and develop and then delete the release branch.
Yes, exactly.
Feature branches appear and disappear as developers work on single features. Every feature branch is deleted after it's merged in develop. develop is the new "SNAPSHOT".
Yes, but feature branches don't have to be deleted that fast. A feature branch could be left in place for users to try and merge a feature in their own version, or to do bugfixing for a short period in it. It will be decided case by case.
So to sum up, in principle I am
+1 for 1C provided that git allows to bypass the pull request by pushing in the main repo from a fork and that this doesn't generate too much hassle for a developer +1 for 2D provided that I have well understood the semantics of these branches :)
-Thanks, Fabio
On Sat, Apr 2, 2011 at 7:31 PM, Sergiu Dumitriu<[email protected]> wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development. This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release. -- Sergiu Dumitriu http://purl.org/net/sergiu/
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi all, for 1, if we set 1A as a rule, nothing prevents somebody from doing 1B (if they want to allow other people to preview their changes before they are merged in master) or 1C if they want code review, and somebody else pulling their changes in master, right? So I go for 1A as a rule, it's what we have now, it's easy to understand, better suited to our manpower and allows to have all the new stuff in one place as soon as possible (which is also a matter of (wo)manpower). I see the fact that we can have 1B and 1C as a plus of using git instead of svn, as benefits, which is great. Now, about 2, I tend to agree with Fabio's proposal. I read that article and I find it very easily understandable and matching our model. (see below, I have intext comments) On Mon, 2011-04-04 at 16:59 +0200, Sergiu Dumitriu wrote:
On 04/04/2011 03:32 PM, Fabio Mancinelli wrote:
Hi Sergiu,
I've read your mail and I have some quick remarks/questions:
1) Concerning part 1, I like the fact of working on a fork and sending pull requests (solution C), though it seems a bit overkill for committers who "really knows what they are doing". In my particular case I would gladly fork the project in order to have the chance to submit pull requests whenever I think my code needs a review. I think that sending pull requests is only possible if you are working on a fork, so if we want to use github as an effective code-review platform we should always work with forks.
No, you can send "pull requests" even on committed code. In that case the request must be manually closed. So even with direct commits it's possible to ask for code reviews via pull requests.
The overhead of working with a fork could be worked around by selectively pushing stuff to the main repo. For example, if I am working on something I am confident with, I will push my changes to the main repo (that on https://github.com/xwiki) and then pull them in the fork. If I need a code review, I will push to my fork and issue a pull request.
I think this is doable with git, since you can have multiple remotes but I am not an expert so I don't know if this could lead to "hellish" workflows for the developers.
Yes, it's doable.
"git push" pushes to the "origin" repo. "git push myown" pushes to a remote repo called "myown".
What's critical is being careful where each commit goes.
2) Concerning part 2, it's not clear to me what is the lifetime of the branches? Here I am implicitly advertising (again) http://nvie.com/posts/a-successful-git-branching-model/ (I like it a lot because it's simple and cristal clear :))
Yes, I found this one around the time it appeared, and I also liked it a lot. It's similar to D, but from their branch names they use the "master" branch as the most stable one, and not as the development branch. This is useful for forking and checking out "stable" sources, since it will point to the latest release. But personally, as a developer, I prefer to have "master" as the most unstable branch, with
I think I agree with this, master could be latest, meaning latest code that was committed (not released). But this doesn't really matter, it's what it contains that matters. As for the contents, if I understood right, the "stable" branch that you proposed, Sergiu, is not the same as the "master" branch in Fabio's proposal, since the idea of the master branch is that it only gets commits on releases, once per release, and _that is it_, as for the stable branch, it gets commits in RC stage, when stuff need to be thoroughly tested. In short, while master is a "history of stables", stable is "the future stable release". Now, I am also very interested in the lifetime of these branches, which I think we should clearify. From my pov, tags are very important, I always want to see the code that was released in a specific version. I was told that in git a tag is not a copy like in svn, it's a bookmark in a branch. Just to make things clear, I expect this bookmark to be permanent. I like the way these are handled in the model described by Fabio's link, since it's very clear that all the tags will be in master. However, there is one usecase we cannot implement with that model: We release 3.0, merge it in master and tag We release 3.1, merge it in master and tag We release 3.0.1 (from a hotfix branch created from the 3.0 tag), merge it where? and tag where? So we should find an answer to this and then I'm fine with this model, we can go ahead.
the latest code in it. It's all just naming in the end, not very important.
I think that your point D is very similar to it, but it's not clear to me how the release branch is handled. From my point of view nobody is allowed to commit in the stable branch, except the release manager when doing a release. When a release starts a release branch is created from the development branch. The release manager prepares the release in that branch and when she's done she merges everything in stable and develop and then delete the release branch.
Yes, exactly.
Feature branches appear and disappear as developers work on single features. Every feature branch is deleted after it's merged in develop. develop is the new "SNAPSHOT".
Yes, but feature branches don't have to be deleted that fast. A feature branch could be left in place for users to try and merge a feature in their own version, or to do bugfixing for a short period in it. It will be decided case by case.
So to sum up, in principle I am
+1 for 1C provided that git allows to bypass the pull request by pushing in the main repo from a fork and that this doesn't generate too much hassle for a developer +1 for 2D provided that I have well understood the semantics of these branches :)
-Thanks, Fabio
On Sat, Apr 2, 2011 at 7:31 PM, Sergiu Dumitriu<[email protected]> wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
2/ How to move code from development to release: A. Commit and release from the master branch
this is not doable for us, as one usecase is that at RC1 time, we move the currently released version in a branch from which we will release and the trunk becomes version + 1 milestone 1, so that people can still develop. If we do this than everybody must keep their code on their machines until release is done.
B. Develop in feature branches, merge them in the master when ready, release from master
same, for roughly the same reason. Ok, people would commit in feature branches, but one would be able to see how all this stuff looks together unless they create their clone and pull all these branches, etc, in short there'd be no way to create a nightly build of what is in development for the "trunk branch" in milestone.
C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done.
For C and D I have the same observation: I don't think discussing things in terms of "for polishing" or "done-done" is ok, I thought the idea is to get the things in as sooner as possible to allow testing as soon as possible. Having this idea of a very stable clean branch and various stages to get there, first needs a lot of manpower, which we shouldn't assume we have. Then, I cannot imagine an unflawed process through which things would move correctly through these stages: either they will get old in a branch from where nobody pulls them because they're too buggy or something, or they will be pushed through too early because we're late and it has to make this release or something like that. I would think that the answer to the release quality issue is more time to polish, and better discipline about it. More branches to get features through will not fix the issue. It would help organizing QA if we had more manpower, but it will not fix the problem if we don't. I also strongly prefer one place where everything is since removing and adding and removing and adding components and features and things over and over can create integration issues continuously. So in short I am for keeping somewhat the current model, knowing that I have nothing against changing it in the future to a more gitty way of doing things, if we decide we need it. Thanks, Anca
E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development. This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Mon, Apr 4, 2011 at 4:59 PM, Sergiu Dumitriu <[email protected]> wrote:
On 04/04/2011 03:32 PM, Fabio Mancinelli wrote:
Hi Sergiu,
I've read your mail and I have some quick remarks/questions:
1) Concerning part 1, I like the fact of working on a fork and sending pull requests (solution C), though it seems a bit overkill for committers who "really knows what they are doing". In my particular case I would gladly fork the project in order to have the chance to submit pull requests whenever I think my code needs a review. I think that sending pull requests is only possible if you are working on a fork, so if we want to use github as an effective code-review platform we should always work with forks.
No, you can send "pull requests" even on committed code. In that case the request must be manually closed. So even with direct commits it's possible to ask for code reviews via pull requests.
Out of curiosity, how do you do this? Anyway I was thinking to use this mechanism to prevent to incorporate something the committer wants to be reviewed. Having a code review after the changeset has been committed doesn't make too much sense to me... Unless we use this to flag committed things to keep an eye on. Thanks, Fabio
The overhead of working with a fork could be worked around by selectively pushing stuff to the main repo. For example, if I am working on something I am confident with, I will push my changes to the main repo (that on https://github.com/xwiki) and then pull them in the fork. If I need a code review, I will push to my fork and issue a pull request.
I think this is doable with git, since you can have multiple remotes but I am not an expert so I don't know if this could lead to "hellish" workflows for the developers.
Yes, it's doable.
"git push" pushes to the "origin" repo. "git push myown" pushes to a remote repo called "myown".
What's critical is being careful where each commit goes.
2) Concerning part 2, it's not clear to me what is the lifetime of the branches? Here I am implicitly advertising (again) http://nvie.com/posts/a-successful-git-branching-model/ (I like it a lot because it's simple and cristal clear :))
Yes, I found this one around the time it appeared, and I also liked it a lot. It's similar to D, but from their branch names they use the "master" branch as the most stable one, and not as the development branch. This is useful for forking and checking out "stable" sources, since it will point to the latest release. But personally, as a developer, I prefer to have "master" as the most unstable branch, with the latest code in it. It's all just naming in the end, not very important.
I think that your point D is very similar to it, but it's not clear to me how the release branch is handled. From my point of view nobody is allowed to commit in the stable branch, except the release manager when doing a release. When a release starts a release branch is created from the development branch. The release manager prepares the release in that branch and when she's done she merges everything in stable and develop and then delete the release branch.
Yes, exactly.
Feature branches appear and disappear as developers work on single features. Every feature branch is deleted after it's merged in develop. develop is the new "SNAPSHOT".
Yes, but feature branches don't have to be deleted that fast. A feature branch could be left in place for users to try and merge a feature in their own version, or to do bugfixing for a short period in it. It will be decided case by case.
So to sum up, in principle I am
+1 for 1C provided that git allows to bypass the pull request by pushing in the main repo from a fork and that this doesn't generate too much hassle for a developer +1 for 2D provided that I have well understood the semantics of these branches :)
-Thanks, Fabio
On Sat, Apr 2, 2011 at 7:31 PM, Sergiu Dumitriu<[email protected]> wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development. This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release. -- Sergiu Dumitriu http://purl.org/net/sergiu/
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Apr 2, 2011, at 7:31 PM, Sergiu Dumitriu wrote: Hi devs, Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy. = Short version: 1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer I've heard people do C but I don't like too much for the following reasons: * It means finding a developer to review every time which IMO is going to either be very hard to do or that developer will simply approve it without really reviewing the code * It means the master branch will be slow to have the latest changes which means our CI tests won't run as often on them (only close to release dates) which is bad and will make code integration harder * Side note: Even though Git encourages developers to keep their work locally without sharing them we should **NOT** do this and developers should continue to commit every day and not keep code on their machines. This prevents code integration and code reviews. It's easy to casually review 15 lines of code, it's very hard to review 300 lines of code! * Since mails (and diff mails) will continue to be sent code reviews will still be done as before. This is lazy code reviewing and is IMO much better than forced code reviews which I don't see working. It would be a good strategy if we were building a software to send man to Mars for example but for XWiki I favor a lazy code reviewing approach (what we've been doing). 2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch. I vote 1C and 2D. I vote for doing http://nvie.com/posts/a-successful-git-branching-model/ = Long version The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out. On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks". A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore). A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub. == Commit/Development-related strategies A. One central repository, one trunk (subversion-like) Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository. B. One central repository, feature branches Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch. B1. Also use specific helper branches Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version. Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it. C. One aggregated repository, pulling from developers Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers. We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request. Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code. I don't like it much because it means less integration and integration at the last minute. I prefer 15 pair of eyes than 2 pair of eyes. I like the idea of having a "develop" branch which is for the future release where all do developer push to it. They can have temporary feature branches but these need to be as temporary as possible and push asap to the "develop" branch. The idea is that of CI which has to be done ASAP. This is really really key. == Integration/Release-related strategies Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development. Except for RCs This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone). Actually it's highly dangerous only if developers don't provide tests (which is what is happening right now in lots of cases for different reasons). This is what we need to fight. Providing isolation has never been a solution. It's quite the opposite. It's bad and cost way more when you need to integrate your work. It's funny how with git we seem to forget all the development best practices we've learnt over the years. I find myself going back to 2000, that was the last time I've had this kind of discussion ;) Short releases from a development branch is inline with agile development, but personally I find it too dangerous. Most big projects always keep the main development at least one branch away from the release branch. One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me). I definitely don't like to be compared to the linux kernel and wouldn't like to be like them. I also think the comparison is not correct. I really dislike this way of working, pushing integration to the end. I'm against working in this manner. Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overvi ew/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well. IMO we only need 1 develop branch + very temporary feature branches (only when needed for complex features). What we do need to work on is more testable code and more tests. I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality. The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen. So, here are some possible integration strategies: A. Master development (like now) All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development. B. Feature branches All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough. C. Feature+Development+Release branches All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features. D. Feature+Development+Stable+Release branches This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch. E. Feature+Development+Next+Release This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers. We can also impose windows, like 2-4 weeks for a feature to move into the next branch. We could also make faster releases, skipping milestones. and going to 6 week releases. This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization. But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs. Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers! This I agree :) As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release. http://nvie.com/posts/a-successful-git-branching-model/ sounds like a reasonable, in-between, strategy. WDYT? Thanks -Vincent PS: It seems my worry about using git is starting to materialize: it's that developers develop stuff on their own repo locally without pushing fast enough every day (several times per day), thus delaying integration to the last moment. If this happens then the whole git move would have been very bad for xwiki. I hope we're not going there.
On Apr 8, 2011, at 9:16 AM, Vincent Massol wrote:
On Apr 2, 2011, at 7:31 PM, Sergiu Dumitriu wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
I've heard people do C but I don't like too much for the following reasons: * It means finding a developer to review every time which IMO is going to either be very hard to do or that developer will simply approve it without really reviewing the code * It means the master branch will be slow to have the latest changes which means our CI tests won't run as often on them (only close to release dates) which is bad and will make code integration harder * Side note: Even though Git encourages developers to keep their work locally without sharing them we should **NOT** do this and developers should continue to commit every day and not keep code on their machines. This prevents code integration and code reviews. It's easy to casually review 15 lines of code, it's very hard to review 300 lines of code! * Since mails (and diff mails) will continue to be sent code reviews will still be done as before. This is lazy code reviewing and is IMO much better than forced code reviews which I don't see working. It would be a good strategy if we were building a software to send man to Mars for example but for XWiki I favor a lazy code reviewing approach (what we've been doing).
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
I vote for doing http://nvie.com/posts/a-successful-git-branching-model/
One detail. I think I'd prefer to have master = develop branch and have a stable branch. The reason is to make people discover the latest changes first. Thanks -Vincent
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
I don't like it much because it means less integration and integration at the last minute. I prefer 15 pair of eyes than 2 pair of eyes.
I like the idea of having a "develop" branch which is for the future release where all do developer push to it. They can have temporary feature branches but these need to be as temporary as possible and push asap to the "develop" branch. The idea is that of CI which has to be done ASAP. This is really really key.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development.
Except for RCs
This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Actually it's highly dangerous only if developers don't provide tests (which is what is happening right now in lots of cases for different reasons). This is what we need to fight. Providing isolation has never been a solution. It's quite the opposite. It's bad and cost way more when you need to integrate your work.
It's funny how with git we seem to forget all the development best practices we've learnt over the years. I find myself going back to 2000, that was the last time I've had this kind of discussion ;)
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
I definitely don't like to be compared to the linux kernel and wouldn't like to be like them. I also think the comparison is not correct.
I really dislike this way of working, pushing integration to the end. I'm against working in this manner.
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
IMO we only need 1 develop branch + very temporary feature branches (only when needed for complex features).
What we do need to work on is more testable code and more tests.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
This I agree :)
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release.
http://nvie.com/posts/a-successful-git-branching-model/ sounds like a reasonable, in-between, strategy.
WDYT?
Thanks -Vincent
PS: It seems my worry about using git is starting to materialize: it's that developers develop stuff on their own repo locally without pushing fast enough every day (several times per day), thus delaying integration to the last moment. If this happens then the whole git move would have been very bad for xwiki. I hope we're not going there.
On Fri, Apr 8, 2011 at 09:37, Vincent Massol <[email protected]> wrote:
On Apr 8, 2011, at 9:16 AM, Vincent Massol wrote:
On Apr 2, 2011, at 7:31 PM, Sergiu Dumitriu wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
I've heard people do C but I don't like too much for the following reasons: * It means finding a developer to review every time which IMO is going to either be very hard to do or that developer will simply approve it without really reviewing the code * It means the master branch will be slow to have the latest changes which means our CI tests won't run as often on them (only close to release dates) which is bad and will make code integration harder * Side note: Even though Git encourages developers to keep their work locally without sharing them we should **NOT** do this and developers should continue to commit every day and not keep code on their machines. This prevents code integration and code reviews. It's easy to casually review 15 lines of code, it's very hard to review 300 lines of code! * Since mails (and diff mails) will continue to be sent code reviews will still be done as before. This is lazy code reviewing and is IMO much better than forced code reviews which I don't see working. It would be a good strategy if we were building a software to send man to Mars for example but for XWiki I favor a lazy code reviewing approach (what we've been doing).
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
I vote for doing http://nvie.com/posts/a-successful-git-branching-model/
One detail. I think I'd prefer to have master = develop branch and have a stable branch.
+1
The reason is to make people discover the latest changes first.
Thanks -Vincent
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
I don't like it much because it means less integration and integration at the last minute. I prefer 15 pair of eyes than 2 pair of eyes.
I like the idea of having a "develop" branch which is for the future release where all do developer push to it. They can have temporary feature branches but these need to be as temporary as possible and push asap to the "develop" branch. The idea is that of CI which has to be done ASAP. This is really really key.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development.
Except for RCs
This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Actually it's highly dangerous only if developers don't provide tests (which is what is happening right now in lots of cases for different reasons). This is what we need to fight. Providing isolation has never been a solution. It's quite the opposite. It's bad and cost way more when you need to integrate your work.
It's funny how with git we seem to forget all the development best practices we've learnt over the years. I find myself going back to 2000, that was the last time I've had this kind of discussion ;)
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
I definitely don't like to be compared to the linux kernel and wouldn't like to be like them. I also think the comparison is not correct.
I really dislike this way of working, pushing integration to the end. I'm against working in this manner.
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
IMO we only need 1 develop branch + very temporary feature branches (only when needed for complex features).
What we do need to work on is more testable code and more tests.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
This I agree :)
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release.
http://nvie.com/posts/a-successful-git-branching-model/ sounds like a reasonable, in-between, strategy.
WDYT?
Thanks -Vincent
PS: It seems my worry about using git is starting to materialize: it's that developers develop stuff on their own repo locally without pushing fast enough every day (several times per day), thus delaying integration to the last moment. If this happens then the whole git move would have been very bad for xwiki. I hope we're not going there.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Apr 2, 2011, at 7:31 PM, Sergiu Dumitriu wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
I've heard people do C but I don't like too much for the following reasons: * It means finding a developer to review every time which IMO is going to either be very hard to do or that developer will simply approve it without really reviewing the code * It means the master branch will be slow to have the latest changes which means our CI tests won't run as often on them (only close to release dates) which is bad and will make code integration harder * Side note: Even though Git encourages developers to keep their work locally without sharing them we should **NOT** do this and developers should continue to commit every day and not keep code on their machines. This prevents code integration and code reviews. It's easy to casually review 15 lines of code, it's very hard to review 300 lines of code! * Since mails (and diff mails) will continue to be sent code reviews will still be done as before. This is lazy code reviewing and is IMO much better than forced code reviews which I don't see working. It would be a good strategy if we were building a software to send man to Mars for example but for XWiki I favor a lazy code reviewing approach (what we've been doing).
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
I vote for doing http://nvie.com/posts/a-successful-git-branching-model/
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
I don't like it much because it means less integration and integration at the last minute. I prefer 15 pair of eyes than 2 pair of eyes. I like the idea of having a "develop" branch which is for the future release where all do developer push to it. They can have temporary feature branches but these need to be as temporary as possible and push asap to the "develop" branch. The idea is that of CI which has to be done ASAP. This is really really key.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development.
Except for RCs
This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Actually it's highly dangerous only if developers don't provide tests (which is what is happening right now in lots of cases for different reasons). This is what we need to fight. Providing isolation has never been a solution. It's quite the opposite. It's bad and cost way more when you need to integrate your work. It's funny how with git we seem to forget all the development best practices we've learnt over the years. I find myself going back to 2000, that was the last time I've had this kind of discussion ;)
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
I definitely don't like to be compared to the linux kernel and wouldn't like to be like them. I also think the comparison is not correct. I really dislike this way of working, pushing integration to the end. I'm against working in this manner.
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
IMO we only need 1 develop branch + very temporary feature branches (only when needed for complex features). What we do need to work on is more testable code and more tests.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
This I agree :)
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release.
http://nvie.com/posts/a-successful-git-branching-model/ sounds like a reasonable, in-between, strategy. WDYT? Thanks -Vincent PS: It seems my worry about using git is starting to materialize: it's that developers develop stuff on their own repo locally without pushing fast enough every day (several times per day), thus delaying integration to the last moment. If this happens then the whole git move would have been very bad for xwiki. I hope we're not going there.
On 04/08/2011 03:17 AM, Vincent Massol wrote:
On Apr 2, 2011, at 7:31 PM, Sergiu Dumitriu wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
I've heard people do C but I don't like too much for the following reasons: * It means finding a developer to review every time which IMO is going to either be very hard to do or that developer will simply approve it without really reviewing the code * It means the master branch will be slow to have the latest changes which means our CI tests won't run as often on them (only close to release dates) which is bad and will make code integration harder * Side note: Even though Git encourages developers to keep their work locally without sharing them we should **NOT** do this and developers should continue to commit every day and not keep code on their machines. This prevents code integration and code reviews. It's easy to casually review 15 lines of code, it's very hard to review 300 lines of code! * Since mails (and diff mails) will continue to be sent code reviews will still be done as before. This is lazy code reviewing and is IMO much better than forced code reviews which I don't see working. It would be a good strategy if we were building a software to send man to Mars for example but for XWiki I favor a lazy code reviewing approach (what we've been doing).
I agree on all of these points and in addition, it's a whole new paradigm which we don't currently employ and one which is best suited for project where there is one final "Linus" who decides what gets merged and what does not. IMO +1 for A
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
I'd like to start off closest to what we have been doing. Where we used to use the sandbox, let's use our own github namespaces. IMO the master branch should always be the development branch. We branch before each release (this way the release process never blocks commits to the trunk). Finally, since we have done okay without feature branches so far, I think they should be an optional tool for us to discover. TL;DR: let's start with something as close to what we have as possible and evolve new strategies. Caleb
I vote for doing http://nvie.com/posts/a-successful-git-branching-model/
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
I don't like it much because it means less integration and integration at the last minute. I prefer 15 pair of eyes than 2 pair of eyes.
I like the idea of having a "develop" branch which is for the future release where all do developer push to it. They can have temporary feature branches but these need to be as temporary as possible and push asap to the "develop" branch. The idea is that of CI which has to be done ASAP. This is really really key.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development.
Except for RCs
This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Actually it's highly dangerous only if developers don't provide tests (which is what is happening right now in lots of cases for different reasons). This is what we need to fight. Providing isolation has never been a solution. It's quite the opposite. It's bad and cost way more when you need to integrate your work.
It's funny how with git we seem to forget all the development best practices we've learnt over the years. I find myself going back to 2000, that was the last time I've had this kind of discussion ;)
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
I definitely don't like to be compared to the linux kernel and wouldn't like to be like them. I also think the comparison is not correct.
I really dislike this way of working, pushing integration to the end. I'm against working in this manner.
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
IMO we only need 1 develop branch + very temporary feature branches (only when needed for complex features).
What we do need to work on is more testable code and more tests.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
This I agree :)
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release.
http://nvie.com/posts/a-successful-git-branching-model/ sounds like a reasonable, in-between, strategy.
WDYT?
Thanks -Vincent
PS: It seems my worry about using git is starting to materialize: it's that developers develop stuff on their own repo locally without pushing fast enough every day (several times per day), thus delaying integration to the last moment. If this happens then the whole git move would have been very bad for xwiki. I hope we're not going there.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Fri, 2011-04-08 at 09:17 +0200, Vincent Massol wrote:
On Apr 2, 2011, at 7:31 PM, Sergiu Dumitriu wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
I've heard people do C but I don't like too much for the following reasons: * It means finding a developer to review every time which IMO is going to either be very hard to do or that developer will simply approve it without really reviewing the code * It means the master branch will be slow to have the latest changes which means our CI tests won't run as often on them (only close to release dates) which is bad and will make code integration harder * Side note: Even though Git encourages developers to keep their work locally without sharing them we should **NOT** do this and developers should continue to commit every day and not keep code on their machines. This prevents code integration and code reviews. It's easy to casually review 15 lines of code, it's very hard to review 300 lines of code! * Since mails (and diff mails) will continue to be sent code reviews will still be done as before. This is lazy code reviewing and is IMO much better than forced code reviews which I don't see working. It would be a good strategy if we were building a software to send man to Mars for example but for XWiki I favor a lazy code reviewing approach (what we've been doing).
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
I vote for doing http://nvie.com/posts/a-successful-git-branching-model/
There's a limitation of this model, I explained in my mail. Here it goes: We release 3.0, merge it in master and tag We release 3.1, merge it in master and tag We release 3.0.1 (from a hotfix branch created from the 3.0 tag), merge and tag where? I'm fine with this model as long as we find a solution for this.
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
I don't like it much because it means less integration and integration at the last minute. I prefer 15 pair of eyes than 2 pair of eyes.
I like the idea of having a "develop" branch which is for the future release where all do developer push to it. They can have temporary feature branches but these need to be as temporary as possible and push asap to the "develop" branch. The idea is that of CI which has to be done ASAP. This is really really key.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development.
Except for RCs
This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Actually it's highly dangerous only if developers don't provide tests (which is what is happening right now in lots of cases for different reasons). This is what we need to fight. Providing isolation has never been a solution. It's quite the opposite. It's bad and cost way more when you need to integrate your work.
It's funny how with git we seem to forget all the development best practices we've learnt over the years. I find myself going back to 2000, that was the last time I've had this kind of discussion ;)
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
I definitely don't like to be compared to the linux kernel and wouldn't like to be like them. I also think the comparison is not correct.
I really dislike this way of working, pushing integration to the end. I'm against working in this manner.
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
IMO we only need 1 develop branch + very temporary feature branches (only when needed for complex features).
What we do need to work on is more testable code and more tests.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
This I agree :)
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release.
http://nvie.com/posts/a-successful-git-branching-model/ sounds like a reasonable, in-between, strategy.
WDYT?
Thanks -Vincent
PS: It seems my worry about using git is starting to materialize: it's that developers develop stuff on their own repo locally without pushing fast enough every day (several times per day), thus delaying integration to the last moment. If this happens then the whole git move would have been very bad for xwiki. I hope we're not going there.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Apr 8, 2011, at 12:05 PM, Luca Anca wrote:
On Fri, 2011-04-08 at 09:17 +0200, Vincent Massol wrote:
On Apr 2, 2011, at 7:31 PM, Sergiu Dumitriu wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
I've heard people do C but I don't like too much for the following reasons: * It means finding a developer to review every time which IMO is going to either be very hard to do or that developer will simply approve it without really reviewing the code * It means the master branch will be slow to have the latest changes which means our CI tests won't run as often on them (only close to release dates) which is bad and will make code integration harder * Side note: Even though Git encourages developers to keep their work locally without sharing them we should **NOT** do this and developers should continue to commit every day and not keep code on their machines. This prevents code integration and code reviews. It's easy to casually review 15 lines of code, it's very hard to review 300 lines of code! * Since mails (and diff mails) will continue to be sent code reviews will still be done as before. This is lazy code reviewing and is IMO much better than forced code reviews which I don't see working. It would be a good strategy if we were building a software to send man to Mars for example but for XWiki I favor a lazy code reviewing approach (what we've been doing).
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
I vote for doing http://nvie.com/posts/a-successful-git-branching-model/
There's a limitation of this model, I explained in my mail. Here it goes:
We release 3.0, merge it in master and tag We release 3.1, merge it in master and tag We release 3.0.1 (from a hotfix branch created from the 3.0 tag), merge and tag where?
We need to create a 3.0 branch for this, which is ok I think. Thanks -Vincent
I'm fine with this model as long as we find a solution for this.
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
I don't like it much because it means less integration and integration at the last minute. I prefer 15 pair of eyes than 2 pair of eyes.
I like the idea of having a "develop" branch which is for the future release where all do developer push to it. They can have temporary feature branches but these need to be as temporary as possible and push asap to the "develop" branch. The idea is that of CI which has to be done ASAP. This is really really key.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development.
Except for RCs
This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Actually it's highly dangerous only if developers don't provide tests (which is what is happening right now in lots of cases for different reasons). This is what we need to fight. Providing isolation has never been a solution. It's quite the opposite. It's bad and cost way more when you need to integrate your work.
It's funny how with git we seem to forget all the development best practices we've learnt over the years. I find myself going back to 2000, that was the last time I've had this kind of discussion ;)
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
I definitely don't like to be compared to the linux kernel and wouldn't like to be like them. I also think the comparison is not correct.
I really dislike this way of working, pushing integration to the end. I'm against working in this manner.
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
IMO we only need 1 develop branch + very temporary feature branches (only when needed for complex features).
What we do need to work on is more testable code and more tests.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
This I agree :)
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release.
http://nvie.com/posts/a-successful-git-branching-model/ sounds like a reasonable, in-between, strategy.
WDYT?
Thanks -Vincent
PS: It seems my worry about using git is starting to materialize: it's that developers develop stuff on their own repo locally without pushing fast enough every day (several times per day), thus delaying integration to the last moment. If this happens then the whole git move would have been very bad for xwiki. I hope we're not going there.
On Fri, 2011-04-08 at 12:13 +0200, Vincent Massol wrote:
On Apr 8, 2011, at 12:05 PM, Luca Anca wrote:
On Fri, 2011-04-08 at 09:17 +0200, Vincent Massol wrote:
On Apr 2, 2011, at 7:31 PM, Sergiu Dumitriu wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
I've heard people do C but I don't like too much for the following reasons: * It means finding a developer to review every time which IMO is going to either be very hard to do or that developer will simply approve it without really reviewing the code * It means the master branch will be slow to have the latest changes which means our CI tests won't run as often on them (only close to release dates) which is bad and will make code integration harder * Side note: Even though Git encourages developers to keep their work locally without sharing them we should **NOT** do this and developers should continue to commit every day and not keep code on their machines. This prevents code integration and code reviews. It's easy to casually review 15 lines of code, it's very hard to review 300 lines of code! * Since mails (and diff mails) will continue to be sent code reviews will still be done as before. This is lazy code reviewing and is IMO much better than forced code reviews which I don't see working. It would be a good strategy if we were building a software to send man to Mars for example but for XWiki I favor a lazy code reviewing approach (what we've been doing).
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
I vote for doing http://nvie.com/posts/a-successful-git-branching-model/
There's a limitation of this model, I explained in my mail. Here it goes:
We release 3.0, merge it in master and tag We release 3.1, merge it in master and tag We release 3.0.1 (from a hotfix branch created from the 3.0 tag), merge and tag where?
We need to create a 3.0 branch for this, which is ok I think.
And keep it forever? I mean all the releases will have their branch forever? That is, if I understand how branches work. If you delete a branch you also delete all tags on it? Thanks, Anca
Thanks -Vincent
I'm fine with this model as long as we find a solution for this.
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
I don't like it much because it means less integration and integration at the last minute. I prefer 15 pair of eyes than 2 pair of eyes.
I like the idea of having a "develop" branch which is for the future release where all do developer push to it. They can have temporary feature branches but these need to be as temporary as possible and push asap to the "develop" branch. The idea is that of CI which has to be done ASAP. This is really really key.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development.
Except for RCs
This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Actually it's highly dangerous only if developers don't provide tests (which is what is happening right now in lots of cases for different reasons). This is what we need to fight. Providing isolation has never been a solution. It's quite the opposite. It's bad and cost way more when you need to integrate your work.
It's funny how with git we seem to forget all the development best practices we've learnt over the years. I find myself going back to 2000, that was the last time I've had this kind of discussion ;)
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
I definitely don't like to be compared to the linux kernel and wouldn't like to be like them. I also think the comparison is not correct.
I really dislike this way of working, pushing integration to the end. I'm against working in this manner.
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
IMO we only need 1 develop branch + very temporary feature branches (only when needed for complex features).
What we do need to work on is more testable code and more tests.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
This I agree :)
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release.
http://nvie.com/posts/a-successful-git-branching-model/ sounds like a reasonable, in-between, strategy.
WDYT?
Thanks -Vincent
PS: It seems my worry about using git is starting to materialize: it's that developers develop stuff on their own repo locally without pushing fast enough every day (several times per day), thus delaying integration to the last moment. If this happens then the whole git move would have been very bad for xwiki. I hope we're not going there.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 04/08/2011 12:16 PM, Luca Anca wrote:
That is, if I understand how branches work. If you delete a branch you also delete all tags on it?
Tags aren't on branches, but on the whole repository. Deleting a branch is just deleting a reference, the data underneath it remains (until you gc --prune). -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Fri, Apr 8, 2011 at 12:05, Luca Anca <[email protected]> wrote:
On Fri, 2011-04-08 at 09:17 +0200, Vincent Massol wrote:
On Apr 2, 2011, at 7:31 PM, Sergiu Dumitriu wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
I've heard people do C but I don't like too much for the following reasons: * It means finding a developer to review every time which IMO is going to either be very hard to do or that developer will simply approve it without really reviewing the code * It means the master branch will be slow to have the latest changes which means our CI tests won't run as often on them (only close to release dates) which is bad and will make code integration harder * Side note: Even though Git encourages developers to keep their work locally without sharing them we should **NOT** do this and developers should continue to commit every day and not keep code on their machines. This prevents code integration and code reviews. It's easy to casually review 15 lines of code, it's very hard to review 300 lines of code! * Since mails (and diff mails) will continue to be sent code reviews will still be done as before. This is lazy code reviewing and is IMO much better than forced code reviews which I don't see working. It would be a good strategy if we were building a software to send man to Mars for example but for XWiki I favor a lazy code reviewing approach (what we've been doing).
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
I vote for doing http://nvie.com/posts/a-successful-git-branching-model/
There's a limitation of this model, I explained in my mail. Here it goes:
We release 3.0, merge it in master and tag We release 3.1, merge it in master and tag We release 3.0.1 (from a hotfix branch created from the 3.0 tag), merge and tag where?
I'm fine with this model as long as we find a solution for this.
This is not supposed to happen. We are not maintaining several stables branches and our rule is that we maintain two branches: the dev and the stable.On svn when we are about to release a X.0 we release what we have in the X-1.0 branch and and close the branch.
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
I don't like it much because it means less integration and integration at the last minute. I prefer 15 pair of eyes than 2 pair of eyes.
I like the idea of having a "develop" branch which is for the future release where all do developer push to it. They can have temporary feature branches but these need to be as temporary as possible and push asap to the "develop" branch. The idea is that of CI which has to be done ASAP. This is really really key.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development.
Except for RCs
This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Actually it's highly dangerous only if developers don't provide tests (which is what is happening right now in lots of cases for different reasons). This is what we need to fight. Providing isolation has never been a solution. It's quite the opposite. It's bad and cost way more when you need to integrate your work.
It's funny how with git we seem to forget all the development best practices we've learnt over the years. I find myself going back to 2000, that was the last time I've had this kind of discussion ;)
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
I definitely don't like to be compared to the linux kernel and wouldn't like to be like them. I also think the comparison is not correct.
I really dislike this way of working, pushing integration to the end. I'm against working in this manner.
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
IMO we only need 1 develop branch + very temporary feature branches (only when needed for complex features).
What we do need to work on is more testable code and more tests.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
This I agree :)
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release.
http://nvie.com/posts/a-successful-git-branching-model/ sounds like a reasonable, in-between, strategy.
WDYT?
Thanks -Vincent
PS: It seems my worry about using git is starting to materialize: it's that developers develop stuff on their own repo locally without pushing fast enough every day (several times per day), thus delaying integration to the last moment. If this happens then the whole git move would have been very bad for xwiki. I hope we're not going there.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Sat, Apr 2, 2011 at 19:31, Sergiu Dumitriu <[email protected]> wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
Big -1 for C for committers (it's obviously a lot better than patches for contributors). My +1 goes to A with B as a good practice but not forced (I would do B myself as much as possible but as soon as the commit does not break the build I'm ok if someone do A).
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
Not sure what is the best for 2/ but -1 for A (everyone is stuck when in RC phase and impossible to have stable/dev versions like now) and B (merging at the last minute will make releases a nightmare).
I vote 1C and 2D.
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development. This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hello all, I wrote a little draft about a dev strategy, which is a sort of a mix between the current strategy and the one described by the "A successful Git branching model" article and what has been discussed on this thread. Here it is: http://dev.xwiki.org/xwiki/bin/view/Drafts/GitDevelopment WDYT about this approach? If we agree, we can keep this page as the documentation page of our process. I tried to describe as clear as possible the process. Feel free to perfect it if needed or discuss to adjust it. There are still 2 things about which I am not 100% sure, the ones marked in the document with the following question marks codes: (?) should all committers push to release branches or only release master is responsible to cherrypick the bug fixes? (??) should we have one release branch per release, including bugfix releases, or a "latest stable release branch" from which we make final + corresponding bugfixes releases? WDYT about these? Thanks a lot, Anca On Sat, 2011-04-02 at 19:31 +0200, Sergiu Dumitriu wrote:
Hi devs,
Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy.
= Short version:
1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer
2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch.
I vote 1C and 2D.
= Long version
The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out.
On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks".
A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore).
A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub.
== Commit/Development-related strategies
A. One central repository, one trunk (subversion-like)
Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository.
B. One central repository, feature branches
Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch.
B1. Also use specific helper branches
Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version.
Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it.
C. One aggregated repository, pulling from developers
Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers.
We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request.
Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code.
== Integration/Release-related strategies
Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development. This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone).
Short releases from a development branch is inline with agile development, but personally I find it too dangerous.
Most big projects always keep the main development at least one branch away from the release branch.
One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me).
Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well.
I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality.
The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen.
So, here are some possible integration strategies:
A. Master development (like now)
All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development.
B. Feature branches
All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough.
C. Feature+Development+Release branches
All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features.
D. Feature+Development+Stable+Release branches
This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch.
E. Feature+Development+Next+Release
This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers.
We can also impose windows, like 2-4 weeks for a feature to move into the next branch.
We could also make faster releases, skipping milestones. and going to 6 week releases.
This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization.
But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs.
Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers!
As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release.
participants (6)
-
Caleb James DeLisle -
Fabio Mancinelli -
Luca Anca -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol