In message <[EMAIL PROTECTED]>, Justin Erenkrantz writes: >yet. But, it does mean that CVS has a very short life expectancy within the >ASF. So, expect one day that infrastructure@ will announce, "No more CVS >after X/YY/ZZZZ. All ASF projects will be migrating to Subversion in X
Excellent. I never understand when programmers, who do something as complicated (to most people) as programming, can't pick up or resist picking up another tool. We learn to program in languages we've never programmed in before in under a day, yet it's hard for us to make the switch to Subversionfrom CVS? It doesn't make sense to me. Subversion has a lot of documentation and tries to stick to CVS command names and flags as much as possible. And I say that as someone who doesn't use svn day in and day out. Personally, I'm waiting for that 1.0 release so I don't have to do dumps/loads every time there's a change in the repository schema. On the product group topic, I think jakarta-oro and jakarta-regexp would benefit greatly from a move to commons.apache.org, but I've not initiated that discussion because I haven't found the time to follow through on the last topic I brought up concerning those projects on the Jakarta PMC list. As far as categorization goes, since Commons houses reusable libraries and components, I don't see any reason why components can't belong to multiple categories. If each component has a set of properties, including name, language(s), type(s) of functionality, binary size, etc., then we can autogenerate a set of static Web pages from the component database (could be a an XML file) that allow prospective users to find components based on their requirements. For example, someone working on a project in C who needs an http client would start by choosing Language.C->Category.Networking->SubCategory.HTTP to find Serf. Someone else might choose Category.Networking->SubCategory.HTTP->Language.Java to find HttpClient Someone with less specific requirements might just look at then entire component list sorted by name and browse the descriptions. I don't see a need for a single taxonomy. That said, we still have to identify the dimensions and categories to build the component database. I expect the idea is it will never get so large that we would need to support dynamic queries because of ongoing subproject promotion to top-level status. daniel
