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
