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

Subject: Re: [boost] RE process (prospective from a retired FreeBSD committer)...
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2011-01-30 08:23:39

Dean Michael Berris wrote:

> 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.

Just to clarify, by "unified thing" I mean a specific URL that everybody
can use to checkout/clone/fork/whatever a version of boost with all the
current changes. You suggestion that I manually pull from N different
repositories seems like a mess to me, sorry.

>> - 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.

I am not sure this addresses my concern in any way. Right now, if I have
a one-letter typo in my library, I fix it, do "svn commit" and then everybody
who checks out trunk a second later gets that fix. With your workflow, it's 
necessary that:

1. I commit the fix locally
2. I push to a publicly available repository
3. I mark the current state of publically available repository as good for
pull 
4. Release managers pull into the official master repository.

It's about 99.9% probability that if (4) requires manual action, it means my
fix won't appear for a month at least. And while you can probably can script
(4), the question arises why we need all this mess, as opposed to direct push
into the official master repository. I am sure that most Boost developers will
prefer this model, as opposed to being forced to "release" their libraries
separately.

> 
>> - 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?

I might have missed your proposed way for such pulling of everything. Could
you spell it again?

>> 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.

Why should it be multiple servers? Apparently, having multiple servers is MORE
work, not less, and so far, I don't see Boost developers voting for having
their libraries hosted elsewhere.

- Volodya

-- 
Vladimir Prus
Mentor Graphics
[phone]