Re: R3.14.8 Status

[Ralph Lange <Ralph.Lange@bessy.de>]

Hi,

Maybe we have to optimize our style of testing/fixing a release shortly 
before it is to be released. (At least: I seem to.)

For the second time today I found the CVS repository changed while I was 
compiling for HP, so in both cases I was cancelling and starting all 
over. On HP, compiling Base takes about 25 min. (background work), 
compiling and running all tests is about 2 hours (foreground work). 
Whenever changes to the repository occur within such an 2.5 hour slot, 
I'm wasting time. Either because for the remaining tests I'm testing an 
outdated version and have to redo everything afterwards, or because I'm 
throwing away the results of the tests that I already did.
Or am I the only one being picky enough trying to do the complete tests 
with the release candidate and not relying on changes not introducing 
side effects?

So lately I find myself not only testing stuff for an deprecated system, 
but also wasting most of the test time because of the constant updates 
to the repository.

Is there a better way to handle this? Should we have CVS-tagged 
release-candidate versions to synchronize our test runs?

Ralph (compiling again....)


Andrew Johnson wrote:

> Ok folks, where are we with this release?  Marty has been running some 
> of his tests, successfully so far, and is working on the rest.
>
> It would be nice to get Banjamin's patch to the logClient library 
> included, which we're expecting tomorrow.
>
> Peter Dennison from Diamond sent me a set of patches for linux-arm 
> which included very similar changes to those that Peter Milne's patch 
> (URL sent to tech-talk on 11/8) supports, but with a different target 
> architecture name.  I'd prefer that we only have one linux-arm target 
> architecture if we can combine the two, possibly using the same 
> approach we took for linux-x86 vs linux-386/486/586/686 targets as 
> regards optimization if that's necessary.  Neither set of configure 
> files is currently in CVS, and using  #ifdef _armv4l_  may not be the 
> best solution - Jeff, should we make this more generic by adding a 
> CA_IMPURE_ENDIAN configuration macro?  I'll ask the two Peters to try 
> and come up with a common set of configure files for linux-arm if they 
> can for the R3.14.9 release.
>
> I don't think we're ready for the 64-bit architectures yet, so they 
> should not hold up the release.
>
> Ernest was reporting a segfault in epicsMessageQueueTestHost on 
> linux-x86 which Eric and he are looking into.
>
> Are there any other outstanding issues that we should wait to be fixed 
> before we release?
>
> I'd like comments on the following Mantis bugs:
>
> #153 - Jeff/Ralph - resolved?
> #154 - Jeff - resolve as Not a Bug or Won't Fix?
> #200 - Marty - is this fixed already?
> #204 - Marty - you may have just fixed this
> #207 - Jeff - mark as Feedback?
> #208 - Jeff/Ralph - resolve as Won't Fix?
> #212 - Jeff - resolve as Won't Fix?
> #223 - Why was this assigned to me?
>
> Janet, do you have anything left to finish off for R3.14.8?
>
> - Andrew