Obsolete packages or code in the LSST stack

Data Management
,
#1

How do we handle obsolete code and packages in the LSST stack?

As an example, during the October 2015 “boot camp”, we decided to update references throughout the stack to boost::unordered_map that are now included in the standard C++ library, but the ap package build broke. It turns out that this package is deprecated, and was known to fail to build, but this was not obvious to someone new to the project. In this case, the ap package was moved to the DM internal lsst-dm repository site and renamed legacy-ap as the result of an RFC.

Based on this experience, our policy for handling obsolete packages appears to be:

  1. File an RFC
  2. If the code is agreed to be deprecated, move it to an internal site such as lsst-dm
  3. Document the change in the RFC comments, and reference the RFC in the new repository to make it clear why and when it was removed from the main stack.
1 Like
#2

Specifically: we move repositories from the lsst GitHub organization to lsst-dm, and prefix their name with the string legacy-. Thus, ap becomes https://github.com/lsst-dm/legacy-ap.

1 Like