I recently created the ap_pipe_testdata package, and found some places where the developer guide could be clarified.
1. Specify in what cases an RFC is not required to add a new package. My pair coder and reviewer agreed with my interpretation that a new testdata package is not "intended for distribution to end users" and I therefore did not need an RFC.
2. Configure things on GitHub for the new package:
- Disable squash and rebase merging (this part is pretty clear as-is)
- The part that's not clear is the steps provided to configure branch protection for master. The screenshots and directions are outdated; the services on the "Integrations and services" screen appear to be deprecated and I am not sure where one would put a "simple Travis script" like the flake8 example. I had to click "Add rule" from the "Branches" screen to get to a screen similar to "Branch protection for master" as shown in the dev guide. However, without something checked under "Require branches to be up to date before merging," it does not let me add a new "rule." So I skipped this. In my situation with a new testdata repo, it seems rather superfluous anyway since there is no code. More guidance is needed here.
- Set the team membership properly. Specifically, for a package like mine, set it to both "Data Management" and "Overlords." This is the step I misunderstood and inadvertently skipped. Please explain what team membership is, how to set it properly (why is there a team called Overlords?!), and mention that Jenkins will pass even if you don't do this, but the daily/weekly build will fail.
3. Explicitly say that you must add setupRequired(new_package_name) or setupOptional(new_package_name) to the appropriate other_package/ups/other_package.table files, i.e., any stack package which imports the new package. And if there are C++ dependencies involved, you also need to update the appropriate other_package/ups/other_package.cfg files. (Please note that giving the full example path to the files which must be updated is helpful throughout, even when there is a link included.)
4. Add the new package to lsst/repos/etc/repos.yaml following the conventions there. Merge this change to master before you attempt to run Jenkins; it is a special case exemption from the usual code review process.
5. If it is a Git LFS-backed repo (which mine was), add optional dependencies to lsst/lsstsw/etc/manifest.remap following the conventions there. Include this in the code review (do not merge it in advance like you must do for the changes in lsst/repos).