incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ariel Constenla-Haile <arie...@apache.org>
Subject Re: [Heads up][code] Apache Lucene updated to version 2.9.4
Date Sun, 13 May 2012 14:18:24 GMT
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 <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?

You expressed it more clearly than me :)


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina

Mime
View raw message