Re: Cleanup Math

[Grant Ingersoll <gs...@apache.org>]

On May 30, 2010, at 11:10 AM, Sean Owen wrote:

> On Sun, May 30, 2010 at 11:03 AM, Benson Margulies
> <bi...@gmail.com> wrote:
>> I wasn't here when you all picked up Colt, but I wonder if we want to
>> pick a middle ground between carrying around @deprecated code that no
>> one feels like testing and deleting it altogether. Work went into IP
>> clearance and all that. I'd identifying the things that look furthest
>> from useful and moving them to a separate 'attic', from which they
>> could be recovered in case someone found a use for them.
> 
> (It is always resurrectable from SVN too.)

A bit harder to find, though.

> 
>> By the way, howcome 'taste' has a BitSet distinct from either the JDK
>> class or the collection BitVector?
> 
> Purely for speed and size -- mostly skipping range checks, cutting out
> fields, etc. It mattered enough since it got used so much.

Those are the reasons Lucene has one too!

Re: Cleanup Math

[Isabel Drost <is...@apache.org>]

On Tue Ted Dunning <te...@gmail.com> wrote:

> I think that this is fine.  Essentially this is a more fine grained
> approach to what we have been doing with deprecated.

+1 from me as well.

The approach also clearly separates stable, but in future versions no
longer supported code (deprecated) from experimental, but in future
versions better supported code. Should make it easier for the user to
decide which pieces of Mahout to use.

Isabel

Re: Cleanup Math

[Ted Dunning <te...@gmail.com>]

I think that this is fine.  Essentially this is a more fine grained approach
to what we have been doing with deprecated.

The real virtue of this is that it promotes visibility of the known good
stuff and thus exerts a good social pressure.

I do think that we need to push for code quality as quickly as is
reasonable, but definitely at the patch level, we should encourage
contributors to post early versions.

On Tue, Jun 1, 2010 at 11:16 PM, Robin Anil <ro...@gmail.com> wrote:

> https://issues.apache.org/jira/browse/HADOOP-6668
>
> Check this out. This looks like a clean way to solve this issue in Mahout
> as
> well. If we annotate each package as public stable, private stable, public
> unstable, and so on and so forth, and keep only the stable ones in the
> javadoc, Users will find the documentations a lot more readable. Plus
> developers can keep adding experimental stuff with bad style as long as it
> is not marked visible. We can keep separate quality levels for each
> visibility. Mahout will always attract experimental code, so instead of
> driving it away and waiting for the quality to go up before committing, we
> can annotate it at the least quality level and when it improves, we can
> change the annotation along with the improvements.
>
> I can help creating a patch like this, if everyone is onboard
>
> Robin
>

Re: Cleanup Math

[Robin Anil <ro...@gmail.com>]

https://issues.apache.org/jira/browse/HADOOP-6668

Check this out. This looks like a clean way to solve this issue in Mahout as
well. If we annotate each package as public stable, private stable, public
unstable, and so on and so forth, and keep only the stable ones in the
javadoc, Users will find the documentations a lot more readable. Plus
developers can keep adding experimental stuff with bad style as long as it
is not marked visible. We can keep separate quality levels for each
visibility. Mahout will always attract experimental code, so instead of
driving it away and waiting for the quality to go up before committing, we
can annotate it at the least quality level and when it improves, we can
change the annotation along with the improvements.

I can help creating a patch like this, if everyone is onboard

Robin