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
> 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
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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk