Subject: Re: [boost] Respecting a projects toolchain decisions
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2010-12-28 08:41:13
Dean Michael Berris wrote:
> 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.
No, I mean that I'll be opposed to visiting 4 different issue trackers
for 4 different components I maintain. I want to see a single list of
issues on my plate, so that I can prioritise them together.
>> 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
I don't think you have proven this, yet. Your proposed split will only
cause pain for me.
>> 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.
glibc, gcc, gdb and binutils all live in the same issue tracker.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk