Bruno Postle wrote: > On Sun 25-Jan-2009 at 13:16 -0500, Yuval Levy wrote: >> By submitting his patch, Lukáš asked for a review. I confirm on both >> Ubuntu and Windows. Does not break anything. I vote to put it in trunk. > > Yes put it in the trunk, it isn't going to get extensive testing any > other way.
The recent discussion about merging patches or branches into trunk got me thinking. Branching out does not always have to be in the public repository. Every checkout is potentially a branch. I'd like to propose the following way of working, which is mostly a formalization of what has been done so far. Let's work with three types of branches: - development branches - release branches - trunk DEVELOPMENT BRANCHES Development branches can be either public (in SVN) or local, if a developer is more comfortable working on his own local copy. The more the merrier. We should facilitate users and developers toying with the code. They should know that what is under "branches" in the repository can be highly interesting. We should provide them with hacking howto's like <http://ultrawide.wordpress.com/2008/11/16/hacking-hugin-part-1/> <http://panospace.wordpress.com/2008/12/30/vedutismo> to guide them into the depth of the code without fear. Once they will discover the joys of hacking, they are more likely to become contributors. In terms of management, I'd set a policy of keeping the branches relevant by cleaning up / closing dev branches when the code flows back to trunk or when the branch is abandoned / becomes obsolete. The definition of abandoned branch for me would be if it has not seen any write activity for six months. Before closing it I would ask publicly (here) if somebody still intends to work on it, and as a closure I would move it to a separate folder called abandoned-branches. A branch becomes obsolete when the feature for which it was started has either been integrated in trunk or the branch has been superseded by the development and it is easier to implement that feature starting from scratch. In those cases I would delete the branch, to avoid users wasting time on them. This would apply to branches in both branches and abandoned-branches folder (as it does not make sense to pick up an abandoned and obsolete branch). The goal is to keep the branches folder clean so that when an outsider hits it instead of trunk he is not wasting time. TRUNK Trunk is the main experimental branch. the policies I suggest adopting for trunk: * it should build for most supported platforms most of the time, but the occasional break is acceptable. * the passage of code from a dev branch to trunk should be fast and uncomplicated. I'd rather see a feature first in trunk and then bugfixed than the other way around. I propose a simple test to decide if code can move from a dev branch to trunk: * the owner of the dev branch declares his work finished - meaning that it works for him * at least one reviewer test it on a different platform and finds that nothing major is broken * the code is not harmful, i.e. it does not break existing functionality Once in trunk, the code will be exposed to broader testing and review, which will reveal bugs and minor functionality break. Occasionally there will be snapshot releases from trunk. All other releases will come from the release branches. RELEASE BRANCHES I'd be very strict about changes to release branches. No new features, just bug fixes to the features that were present at the moment it was branched out from trunk. This is the place to add missing translations and support for not yet supported platforms. It is from these branches that the actual releases will be tagged, tarballs will be created. This includes alphas, betas, release candidates, final releases, bugfix releases. Alpha: really just a tentative and not much better than a snapshot. Must not yet support all languages and platforms and is highly experimental. Old functionality should work as expected, but new functionality is in alpha stage. Beta: supports main languages and main platforms. Most functionality should work, but there still are bugs. Release Candidate: reproducible bugs scheduled to be fixed for the release are gone. Difficult to reproduce and exotic bugs can still exist. This is the time to polish things up. All translations should be in at this time. Final Release: supports all languages and all platforms. Bugfix Release: in case important bugs are fixed in trunk later and are backported. Not very likely, since we don't have much resources and it is anyway better to move to the next release cycle. PRACTICAL IMPLICATIONS In that sense, I would suggest branching out now 0.8. This would freeze the features of 0.8 (i.e. no nona-gpu and no vigra 1.6) and its strings. There is enough food on the plate with PTbatcher, fast-preview, Celeste. And for the next release the main dish will be nona-gpu + vigra 1.6. This should enable focussing on the polishing, clean-up, bugfixes for a release on the release-0.8 branch until we can tag a release-0.8.0. At the same time, the bleeding edge can keep evolving in trunk with the addition of vigra1.6 and soon nona-gpu. there is only one complication to this, which is that from the moment we branch out 0.8 bugfixes will need to be applied to both branches - 0.8 and trunk. The alternative would be to freeze trunk for the time it takes to fix those bugs deemed critical for the 0.8 release and delay broader testing of vigra1.6 and nona-gpu. Both ways are OK for me. In practice, I'd clean up the branches folder by: 1. closing the following branches: - before_gsoc2007/ (obsolete) - dangelo (last change 5 years ago) - gsoc2008_batch_processing/ (successfully integrated in trunk) - gsoc2008_integration (superseded by trunk) - gsoc2008_opengl_preview (successfully integrated in trunk) - gsoc2008_sky_identification (successfully integrated in trunk) - stable (obsolete) - vigra140-branch (obsolete) 2. opening a release-0.8 branch when we are ready, from which eventually 0.8.0 will be tagged 3. keep on working on the work in progress development branches with the goal of integrating them in trunk - gsoc2008_feature_matching - gsoc2008_masking - nona-gpu 4. to be really anally retentive, I'd clean up branches into: -branches/dev/ -branches/releases/ -branches/abandoned/ moving the three branches mentioned in 3. to branches/dev; and moving release-0.7.0 branch in branches/releases/ 5. in tags, I would add a tag to hugin-0.7.0 (tagging the exact SVN revision used for that tarball), and in the future I would tag each tarball before releasing it - tagging against a release branch, not against trunk. Yuv --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
