Tim,
... the entire effort to identify and
assemble collections of software that work together.
I for one would like to thank you for the non-trivial effort that
goes into this. It would be technically straightforward to
produce a new synapps "release" every day based on the latest
release versions of the component module, or even from VCS (for
the truly brave). However doing so would lose much of the value
that synapps provides to non-experts.
Of course I know well the effort involved since I did it myself
three times while at BNL to assemble the synapps debian package,
which diverged following synapps 5.5.
synApps is intended to be upgraded in
place between releases, and contains software
(makeReleaseConsistent.pl, release.pl)
The complaint I would have about this approach is that it
encourages everyone to have a different combination of versions,
which then separate needs validation. For efficiency (which I
assume motivates us all) it would be good to minimize the number
of different combinations of versions.
This is compounded by that fact that no one else know which
combinations have been tested by say, Mark, and which are truly
new.
Of course I don't have a magic solution for this. I suppose one
place to start is documenting which collections of versions are
being used/tested at different facilities. For example, the
current state and history of the debian synapps package is here:
https://github.com/epicsdeb/synapps/blob/master/debian/changelog
Michael
On 11/24/2015 01:00 PM, Mooney, Tim M. wrote:
synApps is intended to be upgraded in
place between releases, and contains software
(makeReleaseConsistent.pl, release.pl) to support that practice,
because that has been a convenient way for us to stay current
with all the disparate development efforts (base, seq, asyn,
motor, autosave, etc.) on which synApps modules depend. The
fact that a synApps release is not compatible with a version of
base released two month later doesn't in my mind invalidate the
entire effort to identify and assemble collections of software
that work together.
When only one or a few module-version changes are needed to
produce a working collection, I think it's not time for a new
synApps release, because the upgrade-in-place strategy handles
that well. But when a module on which many other synApps
modules depends changes, then upgrade-in-place becomes
impractical, and a new synApps release is needed.
This strategy has worked pretty well, I think. In my 20+ years
of running synApps on our beamlines and labs, I have always been
able to run an official synApps release, and I have also been
able to make module-version changes needed by one beamline
without exposing other beamlines to any risk. In this way, the
new module version gets tested at only the beamline that expects
to benefit from it. Once vetted, that module version presents
less risk for inclusion in the next version of synApps.
This vetting of individual modules in older releases of synApps
is important, because it's more efficient and thorough to test
software with the hardware on which it's intended to run, and we
don't own that hardware. We have no beamline at our disposal
for testing. The only way we can test with hardware is to
persuade a beamline to upgrade, and we persuade them by exposing
them only to the new software they've told us they want.
Hi
Henrique,
Personally
I don’t find the concept of synApps releases very
useful. Every official synApps release has
significant bugs and build problems, and is almost
instantly out of date because it lacks major new
features of one or more support modules. In my 20+
years of running synApps on our beamlines and labs I
have never been able to run an official synApps
release.
For
example, in the 11 months since synApps 5-8 was
released the following synApps modules have had a
total of 27 new tagged releases:
alive:
1-0-1
areaDetector/ADCore:
2-2, 2-3, 2-4
asyn:
4-26, 4-27
autosave:
5-6-2, 5-7, 5-7-1
calc:
3-5, 3-6, 3-6-1
caputRecorder:
1-4-3, 1-5, 1-5-1
dxp:
3-5
iocStats:
3.1.14
ip:
2-10
optics:
2-10, 2-11
softGlue:
2-5, 2-6, 2-7
sscan:
2-10-2
stream:
2-6b, 2-6c
xxx:
5-8-4
Each
of these releases either fixes significant bugs, adds
significant new features, or both. At what point
should a new synApps release be made? It will clearly
be obsolete in less than 2 weeks on average, since
there are 27 releases of synApps modules in less than
1 year.
I
would find it much more helpful if rather than
official synApps releases there were simply a list of
known incompatibilities of the latest release of
module X with the latest tagged release of module Y.
Mark
From:
Henrique Almeida [mailto:[email protected]]
Sent: Tuesday, November 24, 2015 8:59 AM
To: Mark Rivers
Cc: Henrique Dante de Almeida;
[email protected] Talk
Subject: Re: error: ‘dbChannel’ has no member
named ‘final_dbr_type’
Mark, I can confirm that
replacing the caputRecorder in synApps 5.8 with the
github master branch solved the problem. However, my
plan was using an unmodified synApps version. You
said that the latest version of each module works
with the latest version of all other modules. But
synApps itself is not working with the latest EPICS
base version. Since EPICS base 3.15.2 was released
in May, then this rule has been broken for synApps
for the last 6 months. Maybe it's time to release
synApps 5.9 ?
2015-11-23 18:15 GMT-02:00 Mark
Rivers <[email protected]>:
You can now find the latest
versions of all the synApps modules in
https://github.com/epics-modules.
There have been 3 releases of caputRecorder since
synApps 5.8.
Generally the latest tagged version of each module
will work with the latest tagged version of all
other modules.
I am using the latest version of all synApps modules
now with no problems.
Mark
-----Original Message-----
From: [email protected]
[mailto:[email protected]]
On Behalf Of Henrique Dante de Almeida
Sent: Monday, November 23, 2015 2:02 PM
To: [email protected] Talk
Subject: error: ‘dbChannel’ has no member named
‘final_dbr_type’
Hello, I'm building synApps 5.8 on a fresh Red
Hat 6.6 install and I'm receiving the following
error:
/usr/bin/gcc -D_GNU_SOURCE -D_DEFAULT_SOURCE
-D_X86_ -DUNIX -Dlinux -O3 -g
-Wall -mtune=generic -m32
-D_FILE_OFFSET_BITS=64 -fPIC -I. -I../O.Common
-I. -I. -I.. -I../../../include/compiler/gcc
-I../../../include/os/Linux -I../../../include
-I/usr/local/epics/base-3.15.2/include/compiler/gcc
-I/usr/local/epics/base-3.15.2/include/os/Linux
-I/usr/local/epics/base-3.15.2/include -c
../caputRecorder.c
../caputRecorder.c: In function
‘myAsDataListener’:
../caputRecorder.c:283: error: ‘dbChannel’ has
no member named ‘final_dbr_type’
(etc.)
It seems that there exists a patch for this
problem:
https://subversion.xor.aps.anl.gov/trac/synApps/changeset/19339
Are there plans for merging this patch in
synApps ? What about a new synApps release ?
|