incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [Heads up][code] Apache Lucene updated to version 2.9.4
Date Sun, 13 May 2012 13:57:55 GMT
On Sat, May 12, 2012 at 9:24 PM, Pedro Giffuni <pfg@apache.org> wrote:
> 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).
>

Whew!  I thought I was the only non-perfect person here ;-)

But seriously, no large development effort can ever rely on perfect
(or near-perfect) developers.  That approach doesn't scale.   We need
to rely on an overall process that can efficiently find errors, and
find them early.

So I wonder, in cases like this, where we're upgrading a library that
might cause functional regressions, whether we should do something
like this:

1) Open a BZ issue for the task, e.g., upgrading a particular library.

2) In the issue, describe the general functionality that may be
effected by the library upgrade

3) This then gives the QA volunteers a "head's up" that they should do
some deeper testing in this area.  (They probably don't read every
message on ooo-commits)

4) It also gives us a place where we can look for producing release
notes for 3.5.

Does this make sense?

-Rob


> 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.
>

Mime
View raw message