It's the same old tension between design and evolution: If these packages will be implemented serially by mostly the same people, then they will likely follow their own precedents and order will follow. If the packages will be implemented in parallel by different sub-teams; however, then it might become chaotic unless there is an initial structure from which parallel leaf growth can occur.
I'm fine with either approach but it seems like a good time to have this conversation. No matter how we accomplish it, some uniformity and consistency will be helpful for our users. For me, I have a problem that involves clustering and dimension reduction so I will probably start my odyssey in those branches. Jeff -----Original Message----- From: Ted Dunning [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 05, 2008 11:28 AM To: [email protected] Subject: Re: Package Structure I wouldn't build out skeletons until somebody starts doing the code. Pick ONE algorithm and do it up and then document it as a sample. Let the implementers of various algorithms do their thing. There is nothing worse to read than a whole lot of code that doesn't actually do anything. On 2/5/08 9:09 AM, "Jeff Eastman" <[EMAIL PROTECTED]> wrote: > I'm looking at the package structure in SVN and it begs for additional > structure. Something like the following seems obvious but needs discussion > since it involves naming conventions. I'd be happy to generate driver, map and > reducer classes in Eclipse just to have some skeletons where real code could > be added later, and also create similar structure in the test branch. It's > just administrative work, turning the crank, but somebody needs to do it and > I'd like to volunteer. > > > > org.apache.mahout. > > classification. > > naïve_bayes. > > svm. > > neural_net > > clustering. > > k_means. > > em. > > regression. > > lwlr. > > lr. > > dimension. > > pca. > > ica. > > gda. > > non_mr. > > hmm. > > rl. > > > > Jeff >
