On Wed, Aug 27, 2008 at 4:42 PM, Bjørn Roald <bjorn@4roald.org> wrote:
I agree in general that point releases are important. However I get the nagging feeling there will always be a conflict of interest between moving forward in features and the maintenance of released libraries features. One question to address here is whether to let library authors and a main boost release team focus on the moving forward part and let others do the maintenance part as far as mechanizing the point release process. Some collaboration between the two efforts would be natural and beneficial for both, but I think it is important that this does not become intrusive. As I see it there are two great reasons for loving boost, it move C++ forward and it provide great production quality libraries. I hope both these can be taken properly care of without getting in each others way.
I like this idea of having many release managers worry about the releasing of suitably tested and properly packaged point/major releases of the library. This way boost library authors can concentrate on maintaining a single version of the library -- the one in trunk for example -- which passes a test suite and performs as expected. What I see though is that the problem with this approach is/are the following: * Changes to libraries can only be made by library authors/maintainers, so if a bug is filed against a certain release (1.35 for example) fixing it would be the responsibility of the authors/maintainers of the library on that branch/release. If it was possible to have bugs fixed by others in a given branch and changes are licensed under the Boost Software License, then letting the authors/maintainers worry about the latest and greatest version of their libraries would be feasible -- and changes from releases are then submitted 'upstream' to be integrated to 'trunk'. * Currently, a release branch is cut from the previous release branch and changes for individual libraries are cherry picked and merged "as seen fit" by authors/maintainers. If it was possible to cut a major release branch from trunk and let a team do the cherry picking of changes that get into trunk back into the major release branch, then the quarterly release can still happen -- one team maintains 1.36 (stable), another 1.37 (latest). Debian has the same process of having a 'stable' branch which lives on its own and has a team managing it (and bug fixes that need to go out), an 'unstable' branch which has the greatest flux but lots of testing as well, and a 'testing' branch which eventually comes from 'unstable' to get merged with (and becomes) 'stable'. Changes from 'unstable' that pass the testing criteria are then merged to 'testing', gets tested, and once it passes gets merged into 'stable'. * Back-porting changes from trunk to point releases as well as 'up-streaming' a patch from point releases to trunk is a tedious process which can only be managed by people other than the library authors/maintainers. This opens up the possibility of greater contribution and opportunity for those who want to contribute to be able to do so without having to contend with the authors'/maintainers' time and bandwidth. If we let authors/maintainers of libraries concentrate on making the libraries better -- supporting new features, experimentation, testing, etc. -- instead of asking them to do the merge and maintenance of released versions, maybe we can stick with the quarterly releases branching from trunk, and letting released versions get maintained at their own pace. We can then start retiring older versions of the library and mark them as 'unsupported' after a certain period of time without having to ask authors/maintainers to keep worrying about previous releases and users of these previous releases.
Test resources are essential and hard to find. Could testers be set up with some sort of master schedule managed by a boost test manager so they test various branches/tar-balls as required and report appropriately? That way the maintainer working on a point release could as required request testing on wide range of platforms without having their own costly setup. Somebody need to be the manager of test resources and give priority as appropriate by controlling the testing schedule to make this work.
One possibility in this regard is to encourage the use of virtual machines in the testing of libraries. Although severely limited, for instance testing of Sun compilers on OpenSolaris and Intel compilers in Linux can be done inside a Virtualbox/VMWare image. Interested testers would just have to set these virtual machines up and offer them as downloads somewhere that people can play around with. One thing that comes to mind is testing of specific compiler versions -- Intel 9/10 on Linux x86, GCC 4.1/4.2/4.3 on Linux x86, etc. -- which can be done by many people at the same time. Patches can be made from within the virtual machines and submitted to authors/maintainers in a systematic fashion for application into release branches and/or trunk.
Some boost-users (or more likely their lawyers and managers) also would like licenses under more traditional commercial terms. Don't ask me why -- but it seems to be a fact of life. Companies such as BoostPro should be free to be maintainer of released major versions and free to dual license as needed to allow all developers to use boost.
IANAL, but the current version of the license is very commercial-software friendly. Can't this be explained to these users instead of allowing the "corruption" of the license by allowing dual-licensing? -- Dean Michael C. Berris Software Engineer, Friendster, Inc.