Re: [boost] RE process (prospective from a retired FreeBSD committer)...

Subject: Re: [boost] RE process (prospective from a retired FreeBSD committer)...
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-29 10:26:45

On Sat, Jan 29, 2011 at 3:55 PM, Vladimir Prus
<vladimir_at_[hidden]> wrote:
> Dave Abrahams wrote:
>
>> However, my vision for Boost is a bit different:
>>
>> * each library has its own Git repo
>>
>> * each library maintainer tests and produces versioned releases of
>> that library on his/her own timetable
>>
>> * the latest release of a library is tagged "STABLE"
>>
>> * When assembling a new Boost release, the release manager marks the
>> "STABLE" revision from each library and begins boost-wide
>> integration/interoperability testing on those revisions
>
> I am rather sceptical about this approach. The goodness of what we have
> now is that there's a single trunk that holds code that is:
>
> - supposedly not worse in test results in all other code,
> - is the newest one satisfying the above constraint
>
> Therefore, if I wish to make sure my code works with new release of Boost,
> of if I wish to check if some bug is fixed, that is the place to go. Further,
> this place is jointly updated by every boost developer.
>
> What you propose breaks this useful thing, because:
>
> - Only release managers "pull" into the unified thing

Not really. Every developer can do the same thing that release
managers do. To get a full Boost locally, you pull from multiple
repositories, and you develop against a "stable" or "tagged" version
of each library in your local repository.

> - Release managers only pull "releases", which, together with delays
> added by release managers, means that a fix to a component will be added
> to the unified thing after considerable delay

Not really either. Release managers can just pull from libraries that
have updates, and even do that incrementally.

More to the point, developers willing to work on just getting a stable
release out (maybe a stable release team or "support engineers") can
contribute to the libraries "upstream" fixes that are found to be
required for the "STABLE" versions for integration to happen.

Actually I would even think that "STABLE" in each library would be a
branch, typically "master" or could easily be just another branch, so
changes that are specific to the "STABLE" version stay in that branch.

> - In practice, release managers will only pull a week or two before the release,
> therefore the unified thing we have now will no longer exists, and two weeks
> before the release we'll get a frankenstein creature that might technically
> pass all tests (though I doubt that), but won't be tested by any users in
> real projects.
>

If everybody had a way of pulling the "latest and greatest" of all the
"STABLE" branches of all the libraries they want to use into their own
git repo, I don't see what's the difference from having everything in
the same place.

Am I missing something?

> So, to reiterate, no matter what tools are proposed, I strongly thing that
> there should always be UNIFIED in-development tree of ENTIRE BOOST to which
> all library maintainers can add changes without coordination with release
> managers.
>

Everyone can have that locally as a conglomeration of all the
libraries they're interested in. I don't see why it has to be just one
server.

> Thanks,

HTH

-- 
Dean Michael Berris
about.me/deanberris