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
