commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: Fixing all warnings? [Was: [VOTE] Release Apache Commons Discovery 0.5-RC1]
Date Tue, 05 Apr 2011 17:14:48 GMT
On Apr 5, 2011, at 3:53, 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.
> 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).
> 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.
I like it. Do alphas go through the same vote process?

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

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

View raw message