commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Fixing all warnings? [Was: [VOTE] Release Apache Commons Discovery 0.5-RC1]
Date Tue, 05 Apr 2011 05:46:27 GMT
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.

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.

We have slowly increasing minutiae roadblocks to releases and I've
moved over the years from "it helps build quality" over to "it gets in
the way of community development".


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

View raw message