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 06:34:23

Dean Michael Berris wrote:

> On Tue, Dec 28, 2010 at 2:50 PM, Vladimir Prus
> <vladimir_at_[hidden]> wrote:
>> Dean Michael Berris wrote:
>>
>>> 1. The signal/noise ratio can be hard to keep down especially if you
>>> have a lot of ground to cover. Consider how you (or any other
>>> maintainer for example) would want to manage a part of the 1000
>>> tickets that are all in the same pile. Sure you can query it many
>>> different ways, but wouldn't it be way easier to just look at 100
>>> issues just for Boost.Regex than it is to spend some time looking at
>>> 1000 issues that might be relevant to Boost.Regex?
>>
>> Michael,
>>
>> you seem to be making very strange points here. I have a saved
>> query in Trac for all the components that I maintain, which is bookmarked
>> in my browser, and once a week, I click "Alt-F2", type "Boost Trac", and
>> examine those tickets without seeing anything I don't care about.
>> Is there a reason you think this approach won't work for everybody? Like,
>> is there a web browser that lacks bookmarks functionality?
>>
> 
> Sure, but the whole point that you have a central place to query the
> information is what's broken -- especially if you have to resort to
> these "hacks" just to filter out what's important for you.
> 
> 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. 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.

Even Linux has a single bug tracker, you know.

- Volodya