Re: [boost] Respecting a projects toolchain decisions

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
>> 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.

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. 

- Volodya