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

We had a decision earlier, when our API's have everything cleaned out, we
will call that 1.0. Now we have made a lot of progress in 0.4. If we do due
diligence, I believe we are good to call next release 1.0. To do that, we
need to first list down the problems we see in current Mahout version and
set some targets to reach to 1.0
Robin

On Mon, Nov 1, 2010 at 11:29 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
>

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
>

I think that classifer/clustering unification and documentation will go a
long way towards the problems that I see remaining.

My guess is that a soft production policy regarding compatibility might be
very useful for 1.0, merging towards a harder policy later.

In that policy, additions to API's would be fairly acceptable if mitigated
by mechanisms such as abstract implementations.  It would be nice to have a
fine-grained deprecation annotation scheme so that we can signal intentions
about the future of different parts of the system.  That would allow use to
maintain just a little bit of cowboy in the right areas.

We will also need to have some mechanism for a "labs" area that has much
looser compatibility guarantees.

On Mon, Nov 1, 2010 at 12:09 PM, Sean Owen <[EMAIL PROTECTED]> wrote:

> 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 Nov 1, 2010, at 3:09 PM, Sean Owen wrote:

> 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.

+1.  I think we could get to 1.0 soon.

>
> (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.

Agreed.

> 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.

I'm not sure I would word it that way.  A few years is a long time.  In the span of two years Lucene has seen improvements of upwards of 10-50x in terms of indexing and search speed.  You simply never know where innovation is coming from.  This is why you have branches such as trunk, 1.X, etc. and you back port, but to say we will be on 1.x for years to come is a very bad thing, IMO.
>
> 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,

Hmmm.  I hope no one just decides they think they know what they can throw away.  I'm all for deprecation, but to me deprecation is about changes to APIs.  I don't know that we should throw away algorithms.  People can simply choose not to use them.  Open source is evolutionary, not revolutionary.  Sometimes it just takes a while for people to realize it is useful to them.  Does that mean we should never throw things away?  Of course not.  It just means we need to think about and discuss it.
> or turn away new code more aggressively that's
> not a fit.

I don't agree we should "aggressively" turn away code.  It simply isn't how open source works.  Community over code.  There is no crystal ball here and you simply never know where the next good idea is going to come from unless you let things ruminate.  We may not commit it right away or we may encourage the contributor to flesh it out more, but turn away is not the right attitude, IMO.  Open source is about scratching your itch and it's about innovation coming from the seeming middle of nowhere.  Does that introduce some chaos?  Yes.  Does it make for better code in the long run?  Absolutely.

-Grant

On Mon, Nov 1, 2010 at 10:59 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:

> I'm not sure I would word it that way.  A few years is a long time.  In the
> span of two years Lucene has seen improvements of upwards of 10-50x in terms
> of indexing and search speed.  You simply never know where innovation is
> coming from.  This is why you have branches such as trunk, 1.X, etc. and you
> back port, but to say we will be on 1.x for years to come is a very bad
> thing, IMO.
>

Yes, and Lucene has always had a clear identity: it's a text indexing and
search engine. It set a clear expectation for what it is (and isn't) going
to do and then delivered. As much as there's a risk in defining a project's
scope and standard narrowly, there's risk in being too loose. I tend to
believe the latter is a slightly larger risk now. Would I rather have half
of 3 more algorithms, or more polish on 3 existing ones? More polish. By all
means, once things are polished, 1.0 is out, let's let anyone pile in
innovations for a loose road map for 1.1, 1.2, 2.0 -- a plan around which
organizations rather than individual hobbyists like me can rally and plan
and begin to depend. I think the free-for-all approach is just fine for 0.x
and think it's fine to stay in that mode as long as it takes -- it's kind of
the definition of "0.x" and I am trying to articulate what it is that "1.x"
means that's different. What is it?

> Hmmm.  I hope no one just decides they think they know what they can throw
> away.  I'm all for deprecation, but to me deprecation is about changes to
> APIs.  I don't know that we should throw away algorithms.  People can simply
> choose not to use them.  Open source is evolutionary, not revolutionary.
>  Sometimes it just takes a while for people to realize it is useful to them.
>  Does that mean we should never throw things away?  Of course not.  It just
> means we need to think about and discuss it.
>

Of course, nobody would delete things without discussion. I think an 'attic'
concept is fine for this too. I'm not talking about removing code because
it's old but possibly useful, but because it's not finished, documented,
tested, or consistent with newer code, and has no foreseeable hope of it.
Once we get to "1.0", everything is implicitly blessed as "all this code is
on purpose and we're going to support this for a while". I think we want to
be able to believe that by 1.0. Not meeting that promise has negative
consequence just as retiring something that someone might used sometime.

> I don't agree we should "aggressively" turn away code.  It simply isn't how
> open source works.  Community over code.  There is no crystal ball here and
> you simply never know where the next good idea is going to come from unless
> you let things ruminate.  We may not commit it right away or we may
> encourage the contributor to flesh it out more, but turn away is not the
> right attitude, IMO.  Open source is about scratching your itch and it's
> about innovation coming from the seeming middle of nowhere.  Does that
> introduce some chaos?  Yes.  Does it make for better code in the long run?
>  Absolutely.
>
>
I accept the point but want to argue the other side since I don't hear
enough of the counter-argument.

Apache doesn't let anyone commit any code they like, community or no. So
there must be a point on the spectrum between accepting anything and
accepting nothing we have to find. I only happen to think we will need to
have a stronger bias towards wanting coherent, tested, documented code
coming in as the project evolves. Not now if you like -- but by "1.0", or
else what does that mean?

Ruminations remain fine. We have patches and branches and still ample wiggle
room to commit and collaborate iteratively in HEAD between releases.

I just think you get what you ask for in a case like this. if bits of ideas
are accepted into the project, we'll end up with lots of people's bits. If
the bar is higher for quality and consistent, I believe people do match the
standard they see and hit that bar. We're already talking about people who
want to do what it takes to contribute something.

Community is the reason I think this. I assert that a bit more standards,
review and roadmap actually attracts more community in the long run. I'm
thinking of big organizations. Can you picture your Twitters of the world
using this? kind of, bits, in a maintained branch, with local modifications,
yes. (In fact I think we know of a few big organizations using it kind of
like this.) That's fine for now but something I think must change before you
can picture it being used as-is, for the most part. And that's the something
that's between here and 1.x that I'm trying to articulate.

Otherwise I don't know what difference there is between 0.4, 0.5, 0.6, 1.0,
2.0?

On Mon, Nov 1, 2010 at 4:54 PM, Sean Owen <[EMAIL PROTECTED]> wrote:

> Apache doesn't let anyone commit any code they like, community or no. So
> there must be a point on the spectrum between accepting anything and
> accepting nothing we have to find. I only happen to think we will need to
> have a stronger bias towards wanting coherent, tested, documented code
> coming in as the project evolves. Not now if you like -- but by "1.0", or
> else what does that mean?
>

That makes a bit of sense... my

>
> Ruminations remain fine. We have patches and branches and still ample
> wiggle
> room to commit and collaborate iteratively in HEAD between releases.
>

Fine.
> I just think you get what you ask for in a case like this. if bits of ideas
> are accepted into the project, we'll end up with lots of people's bits. If
> the bar is higher for quality and consistent, I believe people do match the
> standard they see and hit that bar. We're already talking about people who
> want to do what it takes to contribute something.
>

That is fine for the production ready things, but not everything springs
from the brow
of Zeus fully formed.  There needs to be a mechanism whereby new things can
evolve
to this state.

Perhaps we need the additive inverse of the attic.  An incubator space, if
you will, that can
be used to add new capabilities for community commentary and improvement.
 The life
cycle will be that things in the incubator will have to be accepted into
Mahout or move into
the attic.  That allows some of both world views.

This is similar in many ways to the function of the Lucene contrib
directory, but that
function has always confused people.  I would rather just call it incubator.

Otherwise I don't know what difference there is between 0.4, 0.5, 0.6, 1.0,
> 2.0?
>

Back compatibility.

On Nov 1, 2010, at 8:19 PM, Ted Dunning wrote:

> On Mon, Nov 1, 2010 at 4:54 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
>
>> Apache doesn't let anyone commit any code they like, community or no. So
>> there must be a point on the spectrum between accepting anything and
>> accepting nothing we have to find. I only happen to think we will need to
>> have a stronger bias towards wanting coherent, tested, documented code
>> coming in as the project evolves. Not now if you like -- but by "1.0", or
>> else what does that mean?
>>
>
> That makes a bit of sense... my
>
>>
>> Ruminations remain fine. We have patches and branches and still ample
>> wiggle
>> room to commit and collaborate iteratively in HEAD between releases.
>>
>
> Fine.
>
>
>> I just think you get what you ask for in a case like this. if bits of ideas
>> are accepted into the project, we'll end up with lots of people's bits. If
>> the bar is higher for quality and consistent, I believe people do match the
>> standard they see and hit that bar. We're already talking about people who
>> want to do what it takes to contribute something.
>>
>
> That is fine for the production ready things, but not everything springs
> from the brow
> of Zeus fully formed.  There needs to be a mechanism whereby new things can
> evolve
> to this state.
>
> Perhaps we need the additive inverse of the attic.  An incubator space, if
> you will, that can
> be used to add new capabilities for community commentary and improvement.
> The life
> cycle will be that things in the incubator will have to be accepted into
> Mahout or move into
> the attic.  That allows some of both world views.
>

I'd say it is more the difference between trunk and X.Y.  Trunk is where you can innovate.  It's longer term.  A revision branch is dedicated to back compatibility and incremental improvements, sometimes fed from trunk.

On Nov 1, 2010, at 7:54 PM, Sean Owen wrote:

> On Mon, Nov 1, 2010 at 10:59 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>
>> I'm not sure I would word it that way.  A few years is a long time.  In the
>> span of two years Lucene has seen improvements of upwards of 10-50x in terms
>> of indexing and search speed.  You simply never know where innovation is
>> coming from.  This is why you have branches such as trunk, 1.X, etc. and you
>> back port, but to say we will be on 1.x for years to come is a very bad
>> thing, IMO.
>>
>
> Yes, and Lucene has always had a clear identity: it's a text indexing and
> search engine.

Ah, but it is more than that, a lot more.  I guess it depends on how you define the identity.  For me, Mahout was always conceived as a place for machine learning algorithms that helped people solve real problems.  So, us having some less used algorithms that could use some more polish isn't a bad thing.  We just need to label them as such and encourage anyone who wants to pick them up to contribute back.

> It set a clear expectation for what it is (and isn't) going
> to do and then delivered. As much as there's a risk in defining a project's
> scope and standard narrowly, there's risk in being too loose. I tend to
> believe the latter is a slightly larger risk now. Would I rather have half
> of 3 more algorithms, or more polish on 3 existing ones? More polish.

I'm never going to argue against more polish, but I don't think the two are mutually exclusive.  Polish doesn't happen overnight.  People are free to contribute where they see fit.  If you care about polish, then by all means polish.  I'm thankful you want to polish.  I like to polish sometimes and other times I like to do some basic piece of an implementation/algorithm that just might be a seed for someone else to get over a hump that they can then contribute back to on.

One of the most innovative things that ever happened in Lucene happened in Lucene 2.3. A minor release.  All the old capability was pretty well polished and "worked" for many, but the new, somewhat less polished stuff blew the old stuff away.  It took 6-8 months to polish, but it was useful to a whole lot of people w/o the polish right away.  Trunk users are very important for the life of a project.

> By all
> means, once things are polished, 1.0 is out, let's let anyone pile in
> innovations for a loose road map for 1.1, 1.2, 2.0 -- a plan around which
> organizations rather than individual hobbyists like me can rally and plan
> and begin to depend. I think the free-for-all approach is just fine for 0.x
> and think it's fine to stay in that mode as long as it takes -- it's kind of
> the definition of "0.x" and I am trying to articulate what it is that "1.x"
> means that's different. What is it?

In my experience, planning in open source with developers who all work disparate hours and for disparate companies and disparate "itches" is very hard to do.  Doing releases based on a feel is one thing, but saying what exactly will be in a release in a specific time period is much, much harder, especially given some larger amount of time.  Of course we should try to coordinate, but you simply will be hard pressed to turn away good work, or even postpone good work simply because it isn't in some plan.  Again, just look at the 2.3 release in Lucene.  McCandless shows up one day and says "I have an idea for a 10-50x improvement in speed" and then goes about showing it.  We'd have been stupid to turn it away or put it off for the next release.   Organizations depend on open source when the open source has compelling features and polish that they can take advantage of, but you also have to keep in mind, especially with machine learning, that sometimes people just need a germ of an idea to go build from.   Besides, the field is rapidly evolving.  You can see this in the recommender space as well as all the other ones.

In summary, I'm for the general notion of saying "we wish to travel in a northerly direction", but if we happen upon a nice restaurant on the way, let's stop and have a meal b/c we all know we gotta eat at some point in time, so it might as well be when we see a place we like.  And, if we happen to end up traveling north east a little bit too, that's not a big deal either.
Agreed.
Yes and no.  The bar thing is tricky.  You set it too high and you turn people/ideas away that can grow into more capabilities.    However, I agree we can manage it.  I just don't want it to be any rigid set of rules (not that you are proposing it.)
They already are... ;-)
You will always have early adopters and you will always have "wait and see" approaches.  We can keep both happy.  We can manage this all through the notion of trunk and a stable branch approach.  It's a pretty well-defined model at the ASF and elsewhere.  People who care about polish work on the stable branch.  People who care about innovation work on trunk.  As the stuff on trunk matures it is either backported or spun off into the next stable branch.
It's both features and polish, but I see no reason why a particular version can't contain something that is officially released as experimental.  Every piece of software has its dark areas, regardless of whether it is open or proprietary.  To me, it is merely a labeling problem and not so much a problem of "it shouldn't be there"

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
>

On Nov 1, 2010, at 11:05 PM, Jeff Eastman wrote:

> 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

Definitely.  However, we shouldn't be so rigid as to not allow well-documented breaks within a major version (i.e. 1.x).  We should always strive for back compat within a major release and even across major versions (1.x to 2.x), but I doubt we will ever be able to absolutely guarantee it.  Maintaining it for the sake of maintaining it often leads to a whole lot of clutter in your APIs due to all the deprecations.  Communication with the community is the key, in my book, especially b/c are release cycles aren't all that often (twice a year, it seems)

I do think, however, that trunk + branch tends help mitigate this.

> - 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 the Incubator in principal, but in practice it often is treated separately not so much by developers, but by the lawyers who are approving it.  I've seen this more than once with Lucene's "contrib" modules.  There's a notion that they are second class citizens, when in reality they just aren't needed by everyone in all situations so they aren't marked as core.  

I much prefer we simply put things where they would belong if they were fully baked, but mark them with an annotation such as @mahout.experimental.  As long as they compile and their tests pass, I don't see the harm.  The only way they get better is by people trying them and kicking the tires.  This is true no matter how mature the code is.

At any rate, this is really good stuff for a community to flesh out, so I am glad we are having the conversation.  I'd propose we work to get 1.0 out within the next 6 months or so and then move to the trunk + stable branch model.  Cutting edge stuff goes on trunk, polish goes on both trunk and stable branch (via SVN merge from trunk back to the branch).  As the trunk stuff bakes, we may or may not want to backport it on a case by case basis.  This model works well for most communities at the ASF from what I've seen.

-Grant

Not surprisingly some good thoughts and some convergence on sensible
compromises between competing concerns. I think the code and community are
on a good trajectory as a result. Let's look towards a 1.0 release next. We
will have in mind that what is present now will soon be blessed as 1.0 and
align judgments accordingly.
 On 2 Nov 2010 11:38, "Grant Ingersoll" <[EMAIL PROTECTED]> wrote:
>
> On Nov 1, 2010, at 11:05 PM, Jeff Eastman wrote:
>
>> 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
>
> Definitely. However, we shouldn't be so rigid as to not allow
well-documented breaks within a major version (i.e. 1.x). We should always
strive for back compat within a major release and even across major versions
(1.x to 2.x), but I doubt we will ever be able to absolutely guarantee it.
Maintaining it for the sake of maintaining it often leads to a whole lot of
clutter in your APIs due to all the deprecations. Communication with the
community is the key, in my book, especially b/c are release cycles aren't
all that often (twice a year, it seems)
>
> I do think, however, that trunk + branch tends help mitigate this.
>
>> - 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 the Incubator in principal, but in practice it often is treated
separately not so much by developers, but by the lawyers who are approving
it. I've seen this more than once with Lucene's "contrib" modules. There's a
notion that they are second class citizens, when in reality they just aren't
needed by everyone in all situations so they aren't marked as core.
>
> I much prefer we simply put things where they would belong if they were
fully baked, but mark them with an annotation such as @mahout.experimental.
As long as they compile and their tests pass, I don't see the harm. The only
way they get better is by people trying them and kicking the tires. This is
true no matter how mature the code is.
>
> At any rate, this is really good stuff for a community to flesh out, so I
am glad we are having the conversation. I'd propose we work to get 1.0 out
within the next 6 months or so and then move to the trunk + stable branch
model. Cutting edge stuff goes on trunk, polish goes on both trunk and
stable branch (via SVN merge from trunk back to the branch). As the trunk
stuff bakes, we may or may not want to backport it on a case by case basis.
This model works well for most communities at the ASF from what I've seen.
>
> -Grant

Sean,

Mega kudos for starting a good thread.  These issues needed a good airing.

On Tue, Nov 2, 2010 at 4:53 AM, Sean Owen <[EMAIL PROTECTED]> wrote:

> Not surprisingly some good thoughts and some convergence on sensible
> compromises between competing concerns. I think the code and community are
> on a good trajectory as a result. Let's look towards a 1.0 release next. We
> will have in mind that what is present now will soon be blessed as 1.0 and
> align judgments accordingly.
>  On 2 Nov 2010 11:38, "Grant Ingersoll" <[EMAIL PROTECTED]> wrote:
> >
> > On Nov 1, 2010, at 11:05 PM, Jeff Eastman wrote:
> >
> >> 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
> >
> > Definitely. However, we shouldn't be so rigid as to not allow
> well-documented breaks within a major version (i.e. 1.x). We should always
> strive for back compat within a major release and even across major
> versions
> (1.x to 2.x), but I doubt we will ever be able to absolutely guarantee it.
> Maintaining it for the sake of maintaining it often leads to a whole lot of
> clutter in your APIs due to all the deprecations. Communication with the
> community is the key, in my book, especially b/c are release cycles aren't
> all that often (twice a year, it seems)
> >
> > I do think, however, that trunk + branch tends help mitigate this.
> >
> >> - 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 the Incubator in principal, but in practice it often is treated
> separately not so much by developers, but by the lawyers who are approving
> it. I've seen this more than once with Lucene's "contrib" modules. There's
> a
> notion that they are second class citizens, when in reality they just
> aren't
> needed by everyone in all situations so they aren't marked as core.
> >
> > I much prefer we simply put things where they would belong if they were
> fully baked, but mark them with an annotation such as @mahout.experimental.
> As long as they compile and their tests pass, I don't see the harm. The
> only
> way they get better is by people trying them and kicking the tires. This is
> true no matter how mature the code is.
> >
> > At any rate, this is really good stuff for a community to flesh out, so I
> am glad we are having the conversation. I'd propose we work to get 1.0 out
> within the next 6 months or so and then move to the trunk + stable branch
> model. Cutting edge stuff goes on trunk, polish goes on both trunk and
> stable branch (via SVN merge from trunk back to the branch). As the trunk
> stuff bakes, we may or may not want to backport it on a case by case basis.
> This model works well for most communities at the ASF from what I've seen.
> >
> > -Grant
>