On Tue, Apr 5, 2011 at 12:40 AM, <luc.maison...@free.fr> wrote: > > ----- "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.
Agreed. It's not that fixing warnings are bad, it's that making them release blockers is an anti-pattern. The most painful thing btw is doing a new major version of a component - you get stuck in a "can't release" cycle. We need to solve that one, Lang 3.0 should have been pushing out monthly alphas (on apache.org and in Maven). Gary - that's my major advice for Commons Codec 2.0. Plan on an alpha release every month. Even pick the recurring day. Shove it through and keep it fast. Get the alphas on the Maven repos. Don't allow things to block the monthly release beyond Legal and badly fubar. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
