I've set up a job on Princeton's Jenkins server that builds the pipeline and makes a distribution whenever the pfs_pipe2d package is tagged. The same tag may be added to the other products (datamodel, obs_pfs, drp_stella) before tagging pfs_pipe2d; otherwise the tip of the master branch will be used. The pfs_pipe2d git repo is polled every 5 minutes for new tags.

The build is done in the usual PFS stack on Tiger (source /tigress/HSC/PFS/stack/loadLSST.bash).

Users wishing to use eups distrib install should set their EUPS_PKGROOT based on their system:

• Systems compatible with Springdale Linux 7.6 (based on Redhat/CentOS): https://eups.lsst.codes/stack/redhat/el7/devtoolset-6/miniconda3-4.3.21-10a4fa6|https://eups.lsst.codes/stack/src|http://tigress-web.princeton.edu/~HSC/pfs-drp-2d/Linux64|http://tigress-web.princeton.edu/~HSC/pfs-drp-2d/src
• All other systems: https://eups.lsst.codes/stack/src|http://tigress-web.princeton.edu/~HSC/pfs-drp-2d/src

(Note that the first part, containing eups.lsst.codes is usually set by loadLSST.bash.)

My suggestion is that developers tag pfs_pipe2d whenever they merge to master, and tags should be MM.mm where MM is the major version (set by the development plan) and mm is the minor version, incrementing from 0. E.g., I believe the next tag should be 5.1.

I think this is ready for prime time.

I think this is fine and should be merged to master.

One comment on the tags. We may need to 'reserve' the minor version for formal DRP releases. Can we use a third component, eg. pp in MM.mm.pp, for whenever developers tag pfs_pipe2d?

That's fine with me.

Merged to master.