----- "Henri Yandell" <flame...@gmail.com> a écrit : > 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.
I would never have thought about bugs as an incentive for newcomers. It does make sense. > > 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. I think there is also another criterion: * if there is an overwhelming number of warnings, reduce it drastically to a manageable number There are two reasons for this criterion. The first reason is that when you have hundreds or thousands of javac/javadoc/eclipse/checkstyle/findbugs/clirr/Sebb warnings, it is easy to miss an important one hidden by numerous minor ones. The second reason is that when there are two many warnings, this may also drive wannabe committers away, either because they feel the current team is not interested in quality fixes or because they are afraid by the amount of work to fix things. Luc > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
