Re: [boost] git cherry-pick (Was: RE process (prospective from a retired FreeBSD committer)...)

Subject: Re: [boost] git cherry-pick (Was: RE process (prospective from a retired FreeBSD committer)...)
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-31 03:29:35

On Mon, Jan 31, 2011 at 11:55 AM, Steven Watanabe <watanabesj_at_[hidden]> 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