Hi Matt!!! :) great follow up, thanks for taking care of it!
If someone already knows how the functor design has to be modified to improve it, I can do the log-work and have it released ASAP. Many thanks in advance, all the best!!! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Jan 21, 2012 at 4:28 AM, Matt Benson <gudnabr...@gmail.com> wrote: > 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
