On Sat, May 12, 2012 at 9:24 PM, Pedro Giffuni <[email protected]> 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. >
