Boost logo

Boost :

Subject: Re: [boost] Distributed Development Process (was Re: Development Practices (Proposal Progress))
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-19 03:10:58


On Wed, Jan 19, 2011 at 4:01 PM, Denis Shevchenko
<for.dshevchenko_at_[hidden]> wrote:
> 19.01.2011 11:50, Dean Michael Berris пишет:
>>
>> The reasoning for this is so that there can be more release managers
>> that manage just part of the whole Boost library. This alludes to the
>> similarity with Linux subsystems where you have maintainers that
>> basically ensure that the subsystems they maintain are up to snuff.
>
> +1. I think, it's very good idea.
>
>>
>> ...if you just want to get for example Spirit and all the libraries it
>> depends
>> on and extensions that build upon Spirit only, then you get that
>> distribution.
>
> Okay. And how much distributions we'll have?
>

I don't think there should be an artificial limit -- the beauty of
this approach is that whenever people step up to want to maintain
distributions, it can be as simple as getting some Library Maintainers
or Contributors to get together and have someone be a Trusted Release
Manager -- by having two existing Trusted Release Managers sign with
high trust the key of either a Contributor or a Library Maintainer.
Or, the easier way would be to have a Trusted Release Manager start
that distribution, get some Contributors/Library Maintainers into the
mix, and promote some of them to be Release Managers for a
distribution.

This three-level hierarchy can grow broad and flat allowing eventually
not just a single tree but a forest of hierarchies. I can see a
Boost.Algorithms distribution that can contain multiple libraries and
be a self-contained effort to release just a distribution that
contains algorithms.

The point is the number of distributions scale to the number of people
willing and able to contribute -- this time it's not the process that
will get in the way. :)

HTH

-- 
Dean Michael Berris
about.me/deanberris

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk