> 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
- Navigate by Date:
- Prev:
Re: Compiling alh, MEDM on Snow Leopard (10.6.2) Andrew Johnson
- Next:
Re: Compiling alh, MEDM on Snow Leopard (10.6.2) Bertrand H.J. Biritz
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
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: Compiling alh, MEDM on Snow Leopard (10.6.2) Pelaia II, Tom
- Next:
[BUG?] dbgrep *O > /tmp/toto Emmanuel Mayssat
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|