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: [RELEASE][3.4.1]: current status update
Date Thu, 09 Aug 2012 16:36:23 GMT
On Thu, Aug 9, 2012 at 12:16 PM, Ariel Constenla-Haile
<arielch@apache.org> wrote:
> On Thu, Aug 09, 2012 at 11:25:38AM -0400, Rob Weir wrote:

<snip>

>> But the existence or non-existence of a defect like this is
>> independent of the pace of builds.   Frequent builds and frequent
>> testing is a good thing, IMHO.  We just don't want that to translate
>> into frequent voting ;-)
>
> Please don't mix frequent building on regular basis with what has been
> happening here the last weeks. There have been two, three, RC build
> proposal in the same week. The most notorious is the build announced on
> Monday and the re build on the next day. IMHO this is mainly not fair
> for volunteers doing QA work. Of course, we have the former Symphony QA
> team being payed to work on AOO QA, nevertheless it was Josef (AFAIK
> he's not payed by IBM - correct6 me if I'm worng) who discovered the two
> issues on Sunday, at this last issues were detected by users (or thanks
> to user input, see https://issues.apache.org/ooo/show_bug.cgi?id=120517
> for the mozilla browser plugin).
>

I'd like to understand your concerns better.  In what way is this "not
fair for volunteers doing QA work"?

I hope volunteers don't think that they need to repeat all of their
tests with every build.   The IBM QA engineers certainly don't do a
complete test pass for every build.

It should be possible to do this:

1) Take the first RC of the series and stick with it for a week or
more.  Test it as completely as you want.  So long as a test is not
blocked, you can report all bugs against that RC.  Of course, if
printing crashes, then printing is blocked.

2) The critical bugs that are found are then fixed.  This could be
done in a single new RC or in multiple RC's.  How that is done should
not impact the volunteer testers too much.  They can ignore the
intermediate RC's if they want and continue testing on the first one.
Again, this assumes that testing is not blocked in a given area.

3) Additional RC's are useful because they unblock tests that are
blocked because of bugs.

4) When all critical bugs are fixed then we can do a "light" testing
pass on the final RC, concentrating on areas that were changed in the
final bug fixes.

I agree that it would be difficult for a tester to take every RC and
interrupt their work to install and restart testing on it.  But I
don't think this is necessary.  I'd only reinstall if it fixes a bug
that was of interest to me, or if it unblocks my testing.


-Rob
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina

Mime
View raw message