On Mon, Dec 27, 2010 at 1:12 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Dean Michael Berris wrote:
Right, but if you had something else in place that gave you what Trac gives *and* is faster, more pleasant to use, and had a lot more good things going for it -- like it being hosted not by the Boost server -- then maybe you'd like whatever that is too? :D
Would you mind suggesting a specific project management tool, as well as hosting thereof, and migration scripts?
Not at all. JIRA > Trac, and there are CSV importers from Trac CSV exports to JIRA.
I'm sorry to be blunt, but it has been a long thread, and so far, I don't see any specific engineering suggestions being made, or specific problems listed -- rather, this seems to be a general talk about how good git is in solving Linu{x,s}' problems.
Well, the original post wasn't about any specific engineering steps to be made, so don't expect it to get to anything like that. But, since you asked, here's what I'm thinking: 1. Move Boost away from Subversion and let's use Git instead -- have each library be a separate Git repository, follow the model that Qt and the Linux follow, and have the maintainers develop their libraries at their own pace. Release managers then pull from the different repositories and work along with a team to stabilize a release that is supported as the de-facto Boost release. 2. Use JIRA instead of Trac for better performance and more sane UI/UX for issue tracking and/or project management. 3. Set up a community process for choosing which libraries make it into the Boost distribution, which ones are dropped, whether there are multiple Boost distributions and/or mixes, etc. 4. Change the review process instead from a submission->review->inclusion process that's rigidly scheduled to one that is less rigid and is more fluid. Libraries that are developed for Boost, similar to the stuff that's in the sandbox now, are developed on their own following Boost code guidelines and library structure, play well with the build system (whether it's Boost.Build or CMake), and is phased into the Boost distribution following the community process mentioned in 3. A review can happen anytime, and only every so often a vote happens to indicate whether a certain library is up to Boost standards, and that there's a commitment to maintaining the library in case it does get baked into the Boost distribution. There's a more concrete proposal there somewhere that I think I have to write down somewhere for everyone to comment on, but I'll work on that proposal at a later time when I feel like I have enough to write down. That said, please take the above as a "preview" of what my proposal later on should look like. HTH -- Dean Michael Berris about.me/deanberris