On 4/5/11 12:52 AM, Henri Yandell wrote: > 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. +1 - but I don't recall us ever doing that, really. It took me several [pool] and [dbcp] releases to fill in all the missing javadoc (could be [dbcp] still has some) and while reviewers always pointed out the errors, I don't remember ever seeing a -1 based on checkstyle or even findbugs warnings. I would never -1 a release based on checkstyle errors alone.
I agree with Luc's point though about too many broken windows masking the one where the rain is hitting the electrical stuff. Also, especially in Commons, like it or not, what we release are APIs and APIs are expressed in javadoc. The vast majority of what checkstyle complains about is missing javadoc. Some of that is "silly" but some points to significant documentation weakness and when you go to fix it, you see other errors that can really be confusing for users. So while I agree strongly with your point that checkstyle errors by themselves should never be release blockers, I hope we can summon the energy to "raise all the boats" to a decent level of quality over time and then just keep them there. > 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). Is that because of checkstyle warnings? What is stopping you pushing out the alphas? > 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. The only problem with that approach is how to communicate effectively with users so they know the API is not yet stable (until it is). Same issue with [lang] 3. Otherwise, there is no reason not to do this, other than available RM time. Phil > 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
