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 17:58:20 GMT
On 4/5/11 10:14 AM, Gary Gregory wrote:
> 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
>>> 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?
Yes, anything we release requires a VOTE.

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

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

View raw message