commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: Fixing all warnings? [Was: [VOTE] Release Apache Commons Discovery 0.5-RC1]
Date Tue, 05 Apr 2011 14:39:59 GMT
On 4/5/11 12:52 AM, Henri Yandell wrote:
> On Tue, Apr 5, 2011 at 12:40 AM,  <> wrote:
>> ----- "Henri Yandell" <> a écrit :
>>> On Mon, Apr 4, 2011 at 5:13 AM, Gary Gregory <>
>>> wrote:
>>>> On Apr 4, 2011, at 1:45, Simone Tripodi <>
>>> 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
> 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.

> Hen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message