Dean Michael Berris wrote:
On Tue, Dec 28, 2010 at 7:34 PM, Vladimir Prus <vladimir@codesourcery.com> 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