I'm also +1 on the @experimental annotation idea. Different parts of Mahout are at different levels of maturity and the annotation makes it explicit which parts are still in motion. Trimming out things that are unused/unsupported is also a good idea. I do think anything we can do to improve API consistency across the various sub-projects is valuable.
-----Original Message----- From: Grant Ingersoll [mailto:gsing...@apache.org] Sent: Friday, October 07, 2011 9:42 AM To: dev@mahout.apache.org Subject: Re: Board report draft for October On Oct 7, 2011, at 12:00 PM, Dmitriy Lyubimov wrote: > I support (and supported before) the annotations as maturity tags. In Lucene, we use @lucene.experimental We also should probably looking at trimming back things or moving it to a sandbox. I think Watchmaker is a good first candidate, since I don't think anyone uses it or maintains it and my overtures to the Watchmaker author to join us didn't take. Perhaps that code should just be donated back to that project. > > Also command line API seems to be good. Maybe some solver apis could be > standardized in some ways. > > AbstractJob as it currently exists is more a Tool than an individual step in > a pipeline, perhaps historically driven by a fact that most Mahout pipelines > are one step generic job agnstic of MR specific parameters passed to them, > so this needs some model design work before approach is truly applicable to > any given pipeline. Pipeline execution plan also may be not so trivial which > tools such as oozie exist. Because doing it with utter flexibility is > expensive, and because individual steps are implementation detail not > exposed in API, I don't see big urgency in forcing any abstract > functionality in an internal pipeline execution for as long as they merge > managed parameters with unmanaged configuration passed in via Tool like > base. > On Oct 7, 2011 6:14 AM, "Grant Ingersoll" <gsing...@apache.org> wrote:
