On Sat, Jan 21, 2012 at 4:10 AM, Simone Tripodi <simonetrip...@apache.org> wrote: > 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.
Hi, Simo-- For a few of the items Emmanuel noted, I have recorded new JIRA issues (with him as submitter). For right now if you wanted to simply hit that wiki page and add your thoughts to any of the individual items there (particularly the ones for which I indicated that a discussion might be in order), that would probably be the best thing to keep us moving. Specifically I'm looking for ebourg's feedback so we can reach consensus on the design and move on, but anyone with an interest (including non-committers, *Bruno*!) is welcome to participate as well! Thanks, Matt > > 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
