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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: AreaDetector repository inconsistent |
From: | "Mooney, Tim M." <[email protected]> |
To: | "J. Lewis Muir" <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Thu, 8 Feb 2018 19:25:01 +0000 |
Hi Lewis,
You already know everything I'm going to say. I'll just put it into the context I often see at beamlines.
There's always something going wrong on some beamline somewhere - not just with beamline software, but also with layers of software that beamline staff add on top, and with the state of the beamline that
one user left for the next user, etc. When something goes wrong, and you're having difficulty assigning a cause, you consider everything that is different from the last time you think everything was working. That process is easier if you don't accept any
differences you don't have to accept.
Even if you're confident that a new module version works when driven as the author expected, putting it on a different beamline could expose a race condition that wasn't noticed before, or a new dependence
on the order in which things happen.
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls Group (www.aps.anl.gov) Advanced Photon Source, Argonne National Lab From: J. Lewis Muir <[email protected]>
Sent: Thursday, February 8, 2018 12:42:33 PM To: Mooney, Tim M. Cc: Rivers, Mark L.; Jemian, Pete R.; [email protected] Subject: Re: AreaDetector repository inconsistent On 02/07, Mooney, Tim M. wrote:
> I think synApps_x_y.sh is a good idea. By the way, the reason that > full synApps releases are not more frequent is not mostly about > module incompatibilities, but more about our inability to test. To > thoroughly test synApps, you have to get it deployed on a beamline. > We don't have a test beamline, and beamline staff don't want to expose > their users to questionable software. They are willing to accept a > new module version that hasn't been thoroughly tested if there is a > bug fix or other improvement they need. But they are not willing to > risk problems from a module whose new features they don't care about. > So, as long as we can do single module upgrades, we do them. This > works until someone needs a new version of asyn, or seq, or some other > module that many other modules use. In that case, it's impractical to > upgrade single modules, and a new version of synApps is needed. Hi, Tim! Thanks for the explanation! One thing I don't understand, though, is the part about beamline staff not wanting to expose their users to questionable software. Does this seem consistent with my observation that modules often introduce breaking changes? I don't think it has to do with testing because I think the author of the module tests any bug fix or feature addition before making a new release. Even if the author does not have the hardware, I think the author will at least confirm that the fix or feature works for someone who does have the hardware before making a new release. I don't want to belabor the point, but on the one hand, Mark says he rarely sees breaking changes in modules, and upgrading is straightforward; but on the other hand, your beamline staff are worried about exposing their users to questionable software. What am I missing? Regards, Lewis |