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 10:01:12

On Mon, Dec 27, 2010 at 1:12 PM, Vladimir Prus
<vladimir_at_[hidden]> wrote:
> Dean Michael Berris wrote:
>>
>>
>> Right, but if you had something else in place that gave you what Trac
>> gives *and* is faster, more pleasant to use, and had a lot more good
>> things going for it -- like it being hosted not by the Boost server --
>> then maybe you'd like whatever that is too? :D
>
> Would you mind suggesting a specific project management tool, as well
> as hosting thereof, and migration scripts?
>

Not at all. JIRA > Trac, and there are CSV importers from Trac CSV
exports to JIRA.

> I'm sorry to be blunt, but it has been a long thread, and so far, I
> don't see any specific engineering suggestions being made, or
> specific problems listed -- rather, this seems to be a general
> talk about how good git is in solving Linu{x,s}' problems.
>

Well, the original post wasn't about any specific engineering steps to
be made, so don't expect it to get to anything like that.

But, since you asked, here's what I'm thinking:

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.

2. Use JIRA instead of Trac for better performance and more sane UI/UX
for issue tracking and/or project management.

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. Libraries that are developed for
Boost, similar to the stuff that's in the sandbox now, are developed
on their own following Boost code guidelines and library structure,
play well with the build system (whether it's Boost.Build or CMake),
and is phased into the Boost distribution following the community
process mentioned in 3. A review can happen anytime, and only every so
often a vote happens to indicate whether a certain library is up to
Boost standards, and that there's a commitment to maintaining the
library in case it does get baked into the Boost distribution.

There's a more concrete proposal there somewhere that I think I have
to write down somewhere for everyone to comment on, but I'll work on
that proposal at a later time when I feel like I have enough to write
down.

That said, please take the above as a "preview" of what my proposal
later on should look like.

HTH

-- 
Dean Michael Berris
about.me/deanberris