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
