On Mon, Apr 4, 2011 at 5:13 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > On Apr 4, 2011, at 1:45, Simone Tripodi <simonetrip...@apache.org> wrote: > >> Hi Gary! >> I honestly even thought about it, so sorry! :( Since Discovery >> activity has not been hight since 2008, I just thought adding the >> missing generics support and nothing more :( >> I don't think that should be a blocking issue since we've been >> "overlooked" them for a long time, BTW if we think the effort of >> fixing the checkstyle warnings can help the component health, I'll >> cancel this vote and rollout a new one as soon as I can. >> WDYT? Many thanks in advance for your feedbacks! >> Have a nice day, >> Simo > > IMO a release should be a clean as possible. I also like the release > early release often pattern so you could fix it all next. I am not > sure what your plans are for further releases. If you are working > towards more releases toward a 1.0 then it's ok I suppose.
I increasingly find that feels wrong. We're in the release early/release often business and trying to over-polish not only pushes the release back, but it also decreases the release often as there are less items to do. Somewhere in my gut I feel it might be worse than that. There's a "someone cares" level of quality to achieve, but minor imperfections can drive community. The bugs in our software are our recruitment drive, and getting rid of all of the low-hanging-fruit interferes with that. That seems insane if we put our business developer hats on, but you have to remember that what we do also seems insane. My take away on these internal gastric rumblings has been: * If you are the only committer actively working on a project; and it's been that way for a while; then leave the warts. Focus on the important subjects and get releases out. * If you are newish to driving the project, fix the warnings. It's a good practice and gets you into the code more. * If there are lots of committers; fix some of the warnings. Lead by example but don't do all the work. We have slowly increasing minutiae roadblocks to releases and I've moved over the years from "it helps build quality" over to "it gets in the way of community development". Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
