commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: Fixing all warnings? [Was: [VOTE] Release Apache Commons Discovery 0.5-RC1]
Date Tue, 05 Apr 2011 08:23:21 GMT
Hi Henri,
I agree with that policy, that's why I pushed the digester-05-RC1 so
quickly (also because we've overlooked this problems since 2008 :P),
BW what really blocked the release was the fact that I didn't discuss
which JIRA issues should had been fixed before pushing a new release.
So, taking advantage of the time, since discovery is very small in
size, compared to other components, I thought it would have been nice
having a fresh new clean codebase.
Do you have more suggestion for me before pushing a new RC2? I would
more than glad to follow a generally approved policy.
Thanks in advance, have a nice day!

On Tue, Apr 5, 2011 at 9: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.
> 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.
> Hen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message