EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  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  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: NSLS-II Debian Repository in 2018
From: Anton Derbenev <[email protected]>
To: "J. Lewis Muir" <[email protected]>
Cc: [email protected]
Date: Tue, 13 Feb 2018 19:31:27 -0500
Hello Ralph, Lewis, and Michael,

thanks for your feedback and thoughts. As Michael noted, the question of tools is not the only consideration here. For all the packaging/publishing enterprise, I from the very beginning have two main concerns:

1) Real applicability. While it would be great to have everything packaged for everything, the question of optimal tools and mechanism implementations may be not even viable until a purpose is found. If our entire infrastructure runs Debian, testing grounds for the packaged software are limited. Building a thing is one thing, making sure that it doesn't choke with a segmentation fault during runtime is another thing. I personally do not see it any practical to have a collection of software which is published just for the sake of it. This can be done for fun and consistency of course, but there comes the item #2.

2) Real maintainability. It occurred to me very quickly that packaging is not a one-time project - the fact which is sometimes overlooked. Keeping it properly viable, updated, and tested is a dedicated effort; reacting quickly to upstream changes and user requests defines how useful the packaging is to users. Multi-distribution and multi-platform packaging requires multi-expertise, sometimes application-specific expertise. Unless it is a project with proper resources assigned, I doubt it would be very practical for anyone to commit to such an over-encompassing effort which is quite volatile in its time requirements.

On top of that, there is requirements split. On one hand, our accelerator environment wants stability with no practical reason or sometimes even no practical possibility to put new updates in place. On the other hand, our beamline environment often wants most recent developments which were not published in epicsdeb even, and probably will not be published for some while. The packaging is hence too fast for the first case and too slow for the second case; that is of course a consequence of the amount of work required to make it all "right". The practical outcome that we do what we can with things which we have.

 Maybe in the future? :)

However I am not sure how the future would help with the fact that a successful solution needs constant upkeep...

Anton.

Replies:
Re: NSLS-II Debian Repository in 2018 J. Lewis Muir

Navigate by Date:
Prev: Re: NSLS-II Debian Repository in 2018 J. Lewis Muir
Next: "Inspect Waveforms" in CSS DataBrowser Takashi OBINA
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  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: NSLS-II Debian Repository in 2018 Carlos Pascual
Next: Re: NSLS-II Debian Repository in 2018 J. Lewis Muir
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  <20182019  2020  2021  2022  2023  2024 
ANJ, 21 Feb 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·