On Mon, Jan 31, 2011 at 11:55 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
On 1/30/2011 7:30 PM, Steve M. Robbins wrote:
On Sun, Jan 30, 2011 at 11:14:53PM +0000, Christopher Jefferson wrote:
I think the problem is having a "trunk" which is merged piece-meal into a release branch. This is an unusual method of development, I'm not sure of any other large projects which have the a long-lived trunk and release, with merges from trunk to release. git does not support this well.
It's not just git, in my experience, but humans also have trouble with this model. One of the main problems being that bugs are fixed in the trunk then languish, forgotten, while Boost is released with the same bugs, sometimes for more than one release.
I don't deny that the current system has problems, but it does exist for a good reason. Does anyone remember how long it took to release 1.34?
I do remember that. Back then I don't think git even existed yet though or wasn't getting much usage outside of the Linux development community -- FWIW It's only been around since 2005. IMO, if back then (or especially now) libraries had their own repos to begin with and published "stable" versions and had people stabilizing each library in the stable version, then pulling together a release would largely be a "controlled" process instead of having to wait for everyone to agree that it's ready to release. Really a good example of how this works on a large scale is looking at how Linux distributions are developed. In a Linux distribution every included library, application, and kernel have their own repository -- these are called the upstream repositories -- and the distribution developers maintain a fork of these libraries/applications/kernel. Changes local to the "downstream" repositories (things like packaging, special changes local to the distribution, etc.) are sometimes submitted upstream to the independent project repositories but that means the distribution can be released with the patches local to that distribution. For example RedHat has its own repo's of glibc, gcc, the Linux kernel, etc. which have their own changes that may or may not be merged upstream (but usually the quality of these patches are so good that they make it to the projects up stream, or the maintainers are actually employed by RedHat that it's largely not too much of an issue). Distributions like Ubuntu also do the same thing. It's short of a minor miracle how Linux distributions actually get released with a regular cadence and with high enough quality using this system. What enables it is not just the process and policies but the tools used to support the process and policies better. I hate to sound like a used car salesman but really you should try try it for yourself. ;) -- Dean Michael Berris about.me/deanberris