Sorry to join in late, but I've read all the posts and think there a lot of good ideas in them. - I like the idea that 1.0 means we have some stable, polished code that does what it does really well. Really well. - Backward compatibility of 1.x is important. Our user group is growing and won't appreciate whipsawing - OTOH, I'd hate to see 1.0 mean we no longer tolerate experimental code that is working its way up to production standards - I like Ted's idea of an incubator area where these more tentative features can germinate and someday become production ready - I like Grant's points about the nature of open source vs. corporate development on a schedule. If a corporate sponsor materialized they would - by the act of funding some full-time mahout committers - move the bias more to a corporate schedule but it is still - and should be IMHO, herding cats. - If we had an incubator area for germinating code then I don't see much need for a sunset policy to remove/deprecate stuff that has languished. Who knows when a new contributor will find inspiration and take it to the next level? - Ted's comment about a visible policy and markers for phasing out stuff makes sense. Perhaps an attic works here too. - I sure hope machine learning has not become such a stable discipline that we can button it all up in a major release, ever.
Jeff -----Original Message----- From: Sean Owen [mailto:[email protected]] Sent: Monday, November 01, 2010 12:09 PM To: [email protected] Subject: Re: Why .5? Why not 1.0? I agree. There are not necessarily 6 release before 1.0, and, I suspect it's definitely not more than 2 -- I sure don't imagine an 0.6 myself. (Hadoop's version scheme notwithstanding,) I think 1.0 means many things, including "we think this meets Joe Developer's expectations for production ready software". This means good evidence of no medium- or large-sized bugs, fairly good consistency across the API, fairly good tests and docs. Most significantly, it means some strong commitment to not change or remove APIs without warning. It also probably means that there isn't significantly more to come in Mahout, that what it is at 1.0 is what it will be for a few years. It has to be treated as something tens of thousands of people depend on now, and more as soon as they know they can depend on it. The bad news is that this implies a good amount of grunt work ahead. I personally believe we need to shift modes, away from thinking of the project as an open bazaar of good beginnings of ideas and implementations, away from "seeing what sticks", and towards polishing what's "stuck" already into coherent and consistent modules. It may mean we have to throw away some unsupported, deprecated code, or turn away new code more aggressively that's not a fit. I do think this work will be less fun. But it's necessary to take the project to the 'next level' and that next level is worth reaching. I think it's perhaps an open secret that there are ruminations already about a startup to commercialize Mahout, and a solid 1.0 release is a pre-req for that. I myself already feel in this mode. Being more or less "done" with recommenders I've tried to scrub away micro-level issues in the code. I'd like to next lean on forcing the issue of deleting or using/updating some code in limbo now, as my next contribution towards 1.0. Thoughts? On Mon, Nov 1, 2010 at 5:59 PM, Benson Margulies <[email protected]>wrote: > Folks, > > I see no special reason to believe that we are exact 6 releases from > 1.0. Or two releases. Or 12 releases. It's completely arbitrary. > > So, why not decide that the next release is 1.0, and get on with it? > > --benson >
