Hello Jeremy,


> On Apr 24, 2015, at 8:34 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:
> 
> Hi,
> 
> There are several changes we would eventually like to implement in HPS Java in the near future, and I think it would be good to discuss how we are going to manage change control w.r.t. counting house software and making sure things do not break too much.
> 
> These changes are....
> 
> 1) Updating the ET 14.0 jar to ET 15.0 in order to fix problems with DAQ crashes.
> 
> I am planning on getting this new ET version into the build early next week.  I think this is a blocker item that needs to be solved quickly if it is causing the DAQ to crash, and the level of disruption to (most of) our Java software is likely to be minimal, as ET is essentially only used in the monitoring client.  We will need to thoroughly test our software with the new version though, especially the monitoring app.  This can be done in the counting house or through a VNC session, which I'm hoping to do next week as soon as possible once HPS Java trunk is using the new ET version.

Do we have any evidence that these crashes somehow involved the monitoring app ET client?
Is the new ET-15 incompatible with the ET-14 that is in the current monitoring app?

IF either of these questions is answered with “YES”, then we need to deploy ET-15 in our monitoring code simultaneously with the deployment in the counting house, since otherwise the monitoring system is broken. If there are still other bugs to worry about, we’ll find them and fix them as we go. As Pelle just pointed out, there was such a bug, so we hold off, test, fix that bug, and then deploy simultaneously. 

IF both of these questions is answered with “NO”, then I agree we can take our time and do some testing first before we deploy ET-15.

> 2) Enabling sequential reading of EVIO files.
> 
> It is my understanding that re-enabling the sequential reading of data in the EVIO parser required significant changes and bug fixes to the Java EVIO library, and since our entire recon chain is based on parsing this format, the potential for breakage is pretty significant.  Already, I know of at least one warning message from updating the EVIO version without even enabling the sequential read instead of memory mapping.  So, if we want to work on this right now, my strong preference here would be that the entire trunk is branched, where the sequential reading can be enabled and tested without any potential of breaking the trunk.  In fact, I would propose we go back to the EVIO version we were using (I think it was 4.4.3?) and test 4.4.5 with sequential reading on a branch before updating the trunk at all.  This will make sure we minimize any potential disruptions related to updating this library.

Here I fully agree with you. I will do all the testing on a branch and only when done will I let you know we are ready to merge this onto the trunk. Do you want me to setup the branch, or have you done this already?

> 3) Conditions system refactoring.
> 
> I have a much-improved conditions backend with basically the same functionality, plus some added features, which is far better organized and structured now, as well as easier to use from Java code.  The potential for breaking things is obviously there, but I have been testing thoroughly.  This is implemented on the HPSJAVA-488 branch of trunk.  I am not planning on reintegrating this branch in the near future, though I may not wait until May 16 when we shutdown if I'm convinced that everything is working correctly.  Testing is ongoing with this branch, and I plan to do more of this early next week.  Before doing any merge into trunk, I'll also have others test this as well.  (Any volunteers?)

This sounds nice but not critical to our current ability to run and monitor, and it potentially breaks something. I agree we need to be careful with this one.

Best,
	Maurik


> Are there any other major updates of this kind that should also be discussed?
> 
> Have a good weekend!
> 
> --Jeremy
> 
> ########################################################################
> Use REPLY-ALL to reply to list
> 
> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1