Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 21 Dec 2009 15:10:23 -0700

> No it won't; I will be cherry-picking Ralph's catools commits and a few
> other things like it into the new trunk.

Yes, but then I alone will have to redo all of my self contained patches
(including at least some of the R3.14.11 merge) and upgrades since Sept 3rd.
I would not say anything except that there will be some new substantial
amount of work and also new chances for mistakes.

It seems that before this is done we should be clear on intent; specifically
which changes are intended to be blocked out of the main trunk. Otherwise,
this can turn into an exercise of busy work, recommitting patches and
upgrades, for the patsy.

I can make a short list of what I have done which IMHO should be committed
on the main trunk. These changes will require quite a bit of work if I have
to back annotate them onto the main trunk. All of the changes are IMHO
conservative.

o A substantial number of situation specific patches, fixes, and R3.14.11
merges
o An upgrade to the epicsMutex class to use a namespace and to make the
Guard a subordinate class of Mutex (legacy names still available)
o An upgrade to the epicsMutex class so that it can reference count
instances
o CA client library, and a small amount of other C++ code, was upgraded to
use the new namespace
o The new SMP safe atomic operators - used currently only by the cas
directory and the mutex implementation.

I need to reiterate that if I maintain parallel versions of libCom and the
CA client lib for too long it will eventually become impractical to merge
the upgraded version in with the maintained version because they will have
drifted too far apart. 

The changes in the cas path don?t at this time need to be committed to the
main trunk as they are not currently used by base. However, this directory
is currently commented out of the build so from my perspective discussions
about whether cas, or gdd, should exist there or not appear somewhat
immaterial until the first release of R3.15 goes out.

I see nothing wrong with management of what changes will go into base, but
somehow I am not included in that dialog, and furthermore I also worry that
at some point we are becoming so conservative that we can no longer move
forward - hopefully we are not moving from the bazaar model to the cathedral
model of software development.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: Correspondence

> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Monday, December 21, 2009 10:53 AM
> To: Jeff Hill
> Cc: Ralph Lange
> Subject: Re: september cut
> 
> Hi Jeff,
> 
> On Friday 18 December 2009 18:19:45 you wrote:
> >
> > It occurs to me that if we make the September cut then either Ralph's
> > recent changes to caput/caget/etc will be lost or my half a day fix to
> the
> > CA reference manual will be lost.
> 
> No it won't; I will be cherry-picking Ralph's catools commits and a few
> other
> things like it into the new trunk.  He knows about that and is prepared to
> update the CAref.html file on the new trunk if necessary.
> 
> - Andrew
> --
> The best FOSS code is written to be read by other humans -- Harald Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System