Hi Rob, Pedro, On Sun, May 13, 2012 at 09:57:55AM -0400, Rob Weir wrote: > On Sat, May 12, 2012 at 9:24 PM, Pedro Giffuni <p...@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?
You expressed it more clearly than me :) Regards -- Ariel Constenla-Haile La Plata, Argentina
pgphrYrWDnOYx.pgp
Description: PGP signature
