Le 21/10/2011 17:04, Matt Benson a écrit :
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.
Maybe the Predicate class from [collections] could be reused since [proxy] already depends on this component?
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). 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?
Sorry but that's what released candidates are for. You can't expect everyone to monitor every project continuously, especially the sandbox stuff. Releasing a RC is the right moment to ask for reviews since the code is arguably stabilized.
You'll note that I didn't vote -1 on the release, I just spent 2 hours to review the code and shared my observations thinking it would be useful, but I won't block the release if you think my points are irrelevant. Feel free to release Functor as is and I won't bother you again. But if you take my observations seriously I'll happily stay engaged with this project.
As a side note, in general I wish there were more design/usability reviews on RC calls than checkstyle/compilation verifications.
Emmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
