Experimental Physics and
Industrial Control System

Jeff Hill <[email protected]> · Fri, 14 May 2010 16:02:26 -0000

Hi Ralph,

Sorry about the "sync" commits on the main trunk. Certainly this is in retrospect a bit lazy on my part and I will need to be better in the future. However in my defense, the vast majority of the "sync" commits were for new code - the new server and the atomic primitives in libCom. The vast majority of the rest of them were related to epics mutex name space changes in src/ca.

I was writing code quickly and using the SCC system to transfer back and forth from my home to my workplace. For that type of development when the commit is occurring only to transfer the code between my house and my workplace the minutia comments are less beneficial (it can be hard to come up with insightful comments when you are tired, and leaving late). Note that this was work on new features and not patches. We definitely need the SCC comments for tracking patches. I do see that doing such developments on branches works better. I anticipate that the merge is going to take some extra work however.

The changes to the reference manual are fine. My concern is about maintaining quality in the production system, and from my perspective that can only be achieved if we make major releases on a slower schedule and then keep patching them until they are nearly perfect. My concern is that adding features to a patch series introduces quality control risk.

Thanks,

Jeff

> Thanks, Jeff.
> 
> I did some testing with a setup of two soft IOCs and the example name
> server (that's actually how I found the two issues that were not working
> in the 2008 Codeathon version), focussing on how the new feature behaves
> in different situations ( IOCs and/or name servers going away and coming
> back). I was also running the integration tests all ways (old client -
> new server, new client - old server, new client - new server) to make
> sure it did't obviously break existing behavior. Admittedly I did not
> add any new tests to the test suite, as I found it hard to think of a
> reasonable test. Do you have an idea?
> 
> If your IMHO remark refers to the bug fixes in the reference manual:
> first I was reluctant, but then decided as these were fixing bugs in the
> documentation only, it was not worth creating a new branch for that.
> 
> If you refer to adding a new feature to the 3.14 series: as I told you,
> Andrew wants to discuss at the Codeathon which release this branch
> should be merged to. Note that to escape the large number of meaningless
> "sync" commit comments in the main CVS trunk, we decided a few months
> ago that 3.15 should be developed from forking off the existing 3.14
> branch (that has meaningful commit messages). To make this possible,
> 3.15 only changes in the CVS trunk have to be pulled out into
> feature-branches against the 3.14 release - which is exactly what I was
> doing with the "ca-over-tcp" feature. Now we can decide if that branch
> should be part of 3.14 (before the split) or 3.15 (after the split).
> 
> I removed the comment in udpiiu.cpp as you suggested and pushed the
> change onto LP.
> 
> Cheers,
> Ralph
> 
> 
> On Fri 14 May 2010 1:34:29 Jeff Hill wrote:
> > Review: Approve
> >
> > Looks fine, but its hard to catch everything with a source code review so
> testing is important. IMHO its important to keep bug fix changes and new
> features in different release series, and we seem to be slipping a bit on that
> level of discipline.
> >
> > udpiiu.cpp comment on line 278 prob no-longer applies and can be removed
> >
-- 
https://code.launchpad.net/~ralph-lange/epics-base/ca-over-tcp/+merge/23505
Your team EPICS Core Developers is requested to review the proposed merge of lp:~ralph-lange/epics-base/ca-over-tcp into lp:epics-base.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System