Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4FAF0D30.6000503@apache.org>
Date: Sat, 12 May 2012 20:24:00 -0500
From: Pedro Giffuni <pfg@apache.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:10.0.3) Gecko/20120328 Thunderbird/10.0.3
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: [Heads up][code] Apache Lucene updated to version 2.9.4
References: <4FAEAAC1.2050302@apache.org> <20120512211031.GB12208@localhost>
In-Reply-To: <20120512211031.GB12208@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ariel;

On 05/12/12 16:10, Ariel Constenla-Haile wrote:
> Hi Pedro,
> ...
> IMO when updating external dependencies, the tests should not only include
> the fact that it can be built on all the platforms we support, but
> mainly regressions tests that test if the functionality of the code that
> dependes on these external dependencies is still working.
>
> The steps would be:
>
> 1. make sure it builds
> 2. identify the code that depends on the dependency
> 3. test that the functionality still works.
>
> This is valid also for the apache commons update you did recently.

With Java code there are always two particular things:
1) In theory Java code is platform independent, so even though
I can't test every platform, having it work in UNIX is a really
good sign.
2) One might think the usual "if it ain't broken don't fix it"
philosophy will keep things stable ... but it doesn't: even if we
would like to keep the actual working code set in stone, the
Java VM does get updated and previously working code stops
working or doesn't even build anymore.

Andrew Rist reported a broken case of a linux buildbot with
openjdk7, and he requested the Apache commons update.

Indeed, as you are aware, I am not perfect and you were hit
with many of my early commits that caused breakage (even
when I had all of them reviewed by someone else that knew
the code better than me).

To respond your points, which are perfectly reasonable, in the
case of these last two big changes:

1) The code builds on FreeBSD-amd64, which is my dev. platform.
2) The code has been in use for a while on FreeBSD and/or Debian
Linux for a while. I was very careful to choose only compatible
updates.
3) I did my best to check the specific functionality that may be
affected: it is unlikely I can catch all the use-cases but doing
such changes early in development will help detect any
remaining issue.

This said, we are reaching a level where updating this low-hanging
fruit is not becoming viable anymore. Updating commons-lang to
version 3.1 or Lucene to 3.5 would involve a *lot* of work but I
guess it will get done when it's mandatory to use Java5+.

I know my limitations and I can't really help beyond the updates
I am doing but I am sure this is pretty useful for now.

Pedro.