Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)

Subject: Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-27 23:42:56

On Tue, Dec 28, 2010 at 4:05 AM, Vladimir Prus
<vladimir_at_[hidden]> wrote:
> Dean Michael Berris wrote:
>
>> 1. Move Boost away from Subversion and let's use Git instead -- have
>> each library be a separate Git repository, follow the model that Qt
>> and the Linux follow, and have the maintainers develop their libraries
>> at their own pace. Release managers then pull from the different
>> repositories and work along with a team to stabilize a release that is
>> supported as the de-facto Boost release.
>
> So, instead of having each maintainer merge/push his changes to the
> release branch when he feels like that, you suggest that release managers
> ask maintainers of 70 (or is that 100 already) libraries what revision
> can be pulled to the release? That seems like create scalability problems
> on its own.
>

Instead of looking at it in a binary either-or way, look at it in a
different way.

Maintainers get to develop the libraries at their own pace, allowing
every library to cultivate a community of sorts of users and
developers. I can totally see for example libraries like Spirit to
grow and maintain its own community outside just one Boost community,
and release versions of Spirit at the pace that that community likes.

Of course then Spirit will have its dependencies on libraries like
Proto and MPL, each of which can release versions on which Spirit can
explicitly depend on.

What this allows is for someone to maintain a globbing together of the
requisite Boost libraries that deal exclusively for example with
template metaprogramming (maybe Boost.Meta) that packages different
versions of these libraries into a single distribution that is
maintained by people that aren't necessarily part of the different
projects. Then you can imagine a Boost distribution that just deals
with things like ranges and algorithms that deal with ranges. Then
there's might be a Boost distribution that deals with network stuff,
etc. -- this allows Boost to grow in a scalable manner, and have the
development of each library scale according to the communities that
get built around these libraries.

In the end, what you have are multiple Boost libraries developed in an
optimal manner according to each one's communities, and Boost
distributions that are built up from publicly released component Boost
libraries. Think of how Linux distributions work -- each piece of the
project is separate and there are people that work on just bringing
together these things into a single coherent packaging.

This is the way I'd like to think about making the Boost development
effort more scalable. Instead of building just one Boost distribution,
you can build many that contain different libraries.

>> 3. Set up a community process for choosing which libraries make it
>> into the Boost distribution, which ones are dropped, whether there are
>> multiple Boost distributions and/or mixes, etc.
>>
>> 4. Change the review process instead from a
>> submission->review->inclusion process that's rigidly scheduled to one
>> that is less rigid and is more fluid.
>
> I would suggest you post separately about those proposals. I think that
> the current review process is actually good. It does not prevent anybody
> from using a proposed library in practice and provide real-world feedback.
> However, it encourages relatively deep look -- something that might not
> happen during production use.
>

Sure, that's the plan -- I'd really write up a proposal that has more
detail and concrete steps to take. What I wrote earlier was a high
level view of the plan, which until now is still brewing in my head.
;)

About the review process, the problem with the time limit that I see
is the amount of work required to throughly look at a library usually
doesn't fit in one week. And then the really deeper looks require
quite a bit of discussion to clarify points and make sure that the
reviewer and the library author(s) get to respond to questions and/or
gather feedback regarding the implementation. By making the review
process more of a collaborative development process instead of an "I'm
finished, is it good enough?" thing, you can involve more people and
encourage community building around your library.

Having an incubation project, like the Sandbox, and providing a means
of continuously improving and developing a library -- there's already
a number of libraries in the UnderConstruction wiki page which may be
wanting some love -- and encouraging people to work together to make
the libraries actually get up to a point that would be deemed "Boost
ready" should be better than reserving judgment on whether a library
should be accepted in Boost in a week's (or two weeks) worth of
reviews. Also, making the decision of whether a library should be
accepted in Boost should more or less just be a matter of a vote,
because if you really felt differently about how a certain library
should get developed or if you want to actually influence the
development of a library, it's all just a matter of forking the
repository, making your changes, submitting your changes "upstream"
and letting the community decide whether that change is worth taking
in. This means more collaboration yielding libraries that the
community of developers and users would really want to have, rather
than building a library for a long time "alone" and then hoping that
in the 1/2 weeks that your library is under review that people will
actually care about it.

I should really write all this down into an actionable proposal. ;)

HTH

-- 
Dean Michael Berris
about.me/deanberris