Great idea to create this discussion in the Wiki :) looking forward to seeing a release of functor.
I stopped creating patches for functor to avoid taking decisions without asking here in the list first - sorry, I'm still learning the Apache documentation and understanding the good practices here. There are few issues that I have already filed though, some pointed in the discussion. Feel free to comment, reject or apply patches, no hard feelings. I am using Functor in nebular [1], an Open Source fuzzy logic API. I will model membership functions with Functors, combining it with Apache math 3.0 for sigmoids, gaussian, and so on. This way, it will be possible to create an alternative for Matlab fuzzy toolbox entirely in Java or, another example, create plug-ins for Jenkins, using fuzzy logic to decide when a Build is "not so good" and trigger e-mail alerts. Thanks [1] http://sourceforge.net/p/nebular/blog/ Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com ----- Mensagem original ----- > De: Matt Benson <gudnabr...@gmail.com> > Para: Commons Developers List <dev@commons.apache.org> > Cc: > Enviadas: Sábado, 21 de Janeiro de 2012 1:28 > Assunto: [functor] API, etc., review WAS Re: [VOTE][RESULT] Release Apache > Commons Functor 1.0 based on RC1 > > All who took interest in this discussion three months ago (and still > have any cycles to spare): Please add your thoughts to the discussion > at http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. > > Thanks! > Matt > > On Sun, Oct 23, 2011 at 10:42 AM, Simone Tripodi > <simonetrip...@apache.org> wrote: >> Hi Adrian, >> Of course, we still need a lot of work before next RC, your >> contribution would be more then welcomed! >> Hope to hear from you soon, have a nice day! >> All the best! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> >> >> On Sun, Oct 23, 2011 at 5:26 PM, Adrian Cumiskey >> <adrian.cumis...@gmail.com> wrote: >>> When I take a look at JIRA, Functor currently has only two open issues, > one >>> minor and one trivial. It would be good to capture all the outstanding > work >>> items that people feel are preventing a new RC. I would also be happy > to >>> contribute to improving Functor. >>> >>> Cheers, Adrian. >>> >>> On 23 October 2011 06:46, Simone Tripodi > <simonetrip...@apache.org> wrote: >>> >>>> Hi all guys, >>>> Since 72 hours passed I'm declaring this vote as closed and NOT > passed >>>> with only 2 positive votes from PMCs: >>>> >>>> * Matt Benson >>>> * Simone Tripodi (implicit) >>>> >>>> no other votes were cast. >>>> >>>> We will continue working towards a new RC to submit. >>>> >>>> Thanks to all for your support and patience! >>>> Have a nice weekend, all the best! >>>> Simo >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://simonetripodi.livejournal.com/ >>>> http://twitter.com/simonetripodi >>>> http://www.99soft.org/ >>>> >>>> >>>> >>>> On Fri, Oct 21, 2011 at 6:36 PM, sebb <seb...@gmail.com> > wrote: >>>> > On 21 October 2011 16:04, Matt Benson > <gudnabr...@gmail.com> wrote: >>>> >> On Fri, Oct 21, 2011 at 5:27 AM, sebb > <seb...@gmail.com> wrote: >>>> >>> On 21 October 2011 11:03, Emmanuel Bourg > <ebo...@apache.org> wrote: >>>> >>>> Le 21/10/2011 11:10, Simone Tripodi a écrit : >>>> >>>> >>>> >>>>> So, as you proposed, would be reasonable to > drop the 1.0 and decide >>>> >>>>> upon for a 0.1 as current release? >>>> >>>> >>>> >>>> Yes, or a 1.0-beta with clear indications that > this is a preview >>>> intended to >>>> >>>> gather user feedback. >>>> >>> >>>> >>> I don't think it's ready for beta status yet. >>>> >>> >>>> >>> But - is there any pressing need to make a release? >>>> >> >>>> >> The most immediate thing is that [proxy] 2 needs a unary > predicate. >>>> >> It becomes ridiculous for every component we have to > define such a >>>> >> basic interface in a different way. So [proxy] 2 can > never be >>>> >> released without a [functor] release, etc. >>>> >> >>>> >>> >>>> >>> For developer testing, a snapshot release is probably > sufficient, and >>>> >>> can be updated very quickly - no need for a vote. >>>> >> >>>> >> This is indeed sufficient for the immediate future, but > again, becomes >>>> >> *insufficient* soon enough. I don't personally see > what purpose is >>>> >> served by a 0.x release, but I have to say it's > frustrating to work on >>>> >> a component and only when a release is proposed does > everyone who >>>> >> couldn't have cared less before come out of the > woodwork to suddenly >>>> >> find design issues (issues such as undocumented > @SuppressWarnings come >>>> >> down to personal opinion and I would personally argue they > shouldn't >>>> >> be release blockers, particularly as more often than not > the >>>> >> justification is obvious). >>>> > >>>> > That entirely depends on circumstances; I've seen lots of > cases where >>>> > they are just used to silence warnings, with no attempt to > solve the >>>> > cause of the warning. >>>> > In some (perhaps rare) cases, fixing the warning may point to > a >>>> > fundamental design issue, and/or need to change the API. >>>> > >>>> >> For those of you who have suddenly decided >>>> >> you care about this component: if we discuss and resolve > the >>>> >> fundamental design concerns (i.e. no promises beyond > reaching >>>> >> consensus), can you stay engaged long enough for us to get > this >>>> >> wrapped up? >>>> > >>>> > I'm happy to contribute if I can; I had not realised that > an RC was >>>> > imminent otherwise I might well have dived in earlier. >>>> > >>>> > There are too many components to follow every single one all > the time; >>>> > besides, things are often in a state of flux between releases > - >>>> > there's no point dotting i's and crossing t's if > the entire paragraph >>>> > is about to be rewritten. Been there, done that in other > projects. >>>> > >>>> >> Matt >>>> >> >>>> >>> >>>> >>>> >>>> >>>> Emmanuel Bourg >>>> >>>> >>>> >>>> > --------------------------------------------------------------------- >>>> >>>> To unsubscribe, e-mail: > dev-unsubscr...@commons.apache.org >>>> >>>> For additional commands, e-mail: > dev-h...@commons.apache.org >>>> >>>> >>>> >>>> >>>> >>> >>>> >>> > --------------------------------------------------------------------- >>>> >>> To unsubscribe, e-mail: > dev-unsubscr...@commons.apache.org >>>> >>> For additional commands, e-mail: > dev-h...@commons.apache.org >>>> >>> >>>> >>> >>>> >> >>>> >> > --------------------------------------------------------------------- >>>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> >> For additional commands, e-mail: > dev-h...@commons.apache.org >>>> >> >>>> >> >>>> > >>>> > > --------------------------------------------------------------------- >>>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> > For additional commands, e-mail: dev-h...@commons.apache.org >>>> > >>>> > >>>> >>>> > --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
