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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
