Merlin Fisher-Levine are you suggesting there is a rubinenv-summit conda environment that should be used for all of Jenkins that tests summit-x packages and that would include astroplan? Or are you asking that rubinenv itself (which is nominally solely for lsst-distrib) should start including whatever summit-x packages need?

I would be fine with either of those, I don't think I mind at all - practically speaking they're going to be the same for developers/end-users, though I'm sure architecture will mind about which of those we do (hence asking for KT's input).

My only real thought/point here is that I do think that code which is included in lsst_sitcom, which ships to the summit, and which has to work for observers/commissioning, should be tested as part of Jenkins, and in order to write those tests, those packages need to be available.

I think you're better off not testing Summit packages in Jenkins at all. (I'd like to not test Science Pipelines in Jenkins, but that's a much bigger lift.) If you're testing in GHAs, you can build your own environment, including using or not using rubin-env and augmenting it. I think (but am not certain) that you can even install all of the Science Pipelines in that environment and still fit in a GHA worker. (What you can't do is build the Science Pipelines in a GHA worker.)

Alternatively, test in the TSSW Jenkins, which is much more modern, and which can also add any Summit-needed packages.

Well, that would be a huge departure from the current model, especially as summit code can be broken by core DM changes, and therefore should be part of that CI system, I think. Hsin-Fang Chiang is working on the long-awaited data package for making this possible too... Maybe the three (or more) of us should have a chat about the best approach for that at some point though, it's probably quite beyond the scope of this RFC

Happy to leave this pending for the time being.