Re: [boost] Respecting a projects toolchain decisions

Subject: Re: [boost] Respecting a projects toolchain decisions
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-28 07:04:46

On Tue, Dec 28, 2010 at 7:34 PM, Vladimir Prus
<vladimir_at_[hidden]> wrote:
> Dean Michael Berris wrote:
>
>>
>> Imagine if you had one issue tracker per Boost library. Then you don't
>> have to worry about crafting the queries to get the relevant
>> information in the first place. And then it's going to be easier to
>> develop milestones per library than creating one big milestone and
>> having one giant release. You can then have different workflows per
>> Boost library depending on what the developers of the library are
>> comfortable with.
>
> I'd be very much against the idea of checking 4 different sites as
> opposed to 1 -- at least, until I have 4 pairs of hand to work on
> 4 different projects at the same time.

I'm not talking about having 4 different sites for one library -- I'm
saying, for each Boost library there should be one issue tracker. This
means if you need to check anything regarding that library, then you
go to exactly one place.

I think part of this line of reasoning from me assumes that Boost
isn't just one library, but actually many libraries distributed as a
single downloadable glob. I think that has to change for any
significant progress to be made on the Boost front.

> In fact, I so much dislike
> having to check N different issue trackers that I have a student working
> on a tool to present issues from different trackers in a single UI. However,
> until that project is done, I'd much rather not having things split up
> unnecessary.
>

But what I've been pointing out is that it has come to the point where
it's now necessary to break Boost up into multiple projects, each one
building a community of users/developers that maintain a specific
part.

> Even Linux has a single bug tracker, you know.

But Linux is just one kernel. ;) Imagine globbing together the issues
of glibc, gcc, and the Linux kernel into one issue tracker, just
because they're all part of the LSB -- that's what's happening in
Boost now IMO, which is not scalable.

-- 
Dean Michael Berris
about.me/deanberris