Experimental Physics and Industrial Control System
|
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
- References:
- R3.14.8 Status Andrew Johnson
- Navigate by Date:
- Prev:
Re: R3.14.8 Status/logClient patch Benjamin Franksen
- Next:
Re: [Fwd: R3.14.8 testing: epicsMessageQueueTestHost fails on linux-x86] Marty Kraimer
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: R3.14.8 Status/logClient patch Marty Kraimer
- Next:
R3.14.8 Status Andrew Johnson
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|