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