Team-less repos in Github LSST org

Data Management
#1

Folks,

there are three “special” teams in the LSST Github org (though all our teams are special to me, etc etc)

These are:

  • Data Management
  • DM Externals
  • DM Auxilliaries

These are used in the release process in the following way:

  • Data Management repos that are a dependency of lsst_distrib are tagged with the bare release version, eg. ‘14.0’
  • ‘DM Externals’ that are a dependency of lsst_distrib are tagged with ‘v14.0’ (so that eups does not show it and confuse people who want the upstream semantic versioning to show up)
  • ‘DM Auxilliaries’ are repos that we want to snapshot as part of a relase (eg sdss_demo) but are not an eups dependancy of lsst_distrib

When you create a new repo that is part of the stack, please take a moment to consider if they should belong to one of the above teams.

Below is a list of team-less repos if anyone made theirs team-less by mistake. I am thinking we should have a team like ‘DM Other’ to triage those into, unless anybody thinks it would be confusing.

meas_mosaic
git-lfs-testing
git-lfs-more-testing
miniconda2
LDM-230
LDM-129
pipelines_lsst_io
validation_data_decam
validation_data_hsc
LDM-472
lsst_ci
syseng_db
lsst_qa
jointcal_cholmod
deploy_testing_distrib
miniconda3
pybind11
ephem
sims_catalogs
sims_skybrightness_pre
sims_integrated
sims_survey_fields
LDM-493
meas_extensions_convolved
starlink_ast
display_ginga
community_contactdb_merge
qserv_testscale
os-docker-registry
os-qserv-build-node
ndarray-1
lacquer
pandas
suit-onlinehelp
sims_featureScheduler
LDM-148
verify_metrics
obs_comCam
LDM-512
LDM-294
obs_ctio0m9
LDM-502
LDM-503
all_sky_phot
LSE-63
meas_extensions_astrometryNet
shebangtron
LDM-522
LDM-482
libyaml
LSE-61
LDM-542
LDM-552
LDM-534
LDM-553
LDM-556
LDM-555
marshmallow
ci_ctio0m9
LDM-554
daf_io
repos
ap_verify_hits2015
treecorr
LDM-563
LDM-564
pytest
pytest_flake8
python_mccabe
pyflakes
pycodestyle
flake8
LDM-572
pytest_session2file
pytest_xdist
python_execnet
pytest_forked
display_matplotlib
python_coverage
pytest_cov
pep8_naming
#2

I’ll quickly sort out the third parties that are part of the release. Sims obviously shouldn’t be in any of the DM teams.

#3

I’ve put meas_extensions_convolved and ci_ctio0m9 into the Data Management team.

This is done by hitting the “Settings” button on the package’s front GitHub page (in the third line from the top), selecting “Collaborators & teams” from the left menu, and then selecting a team from the “Add a team” dropdown. I don’t know exactly why the “Settings” button doesn’t always show up; maybe it’s only present if you created the repo in the first place.

#4

Yes. You have to be an admin or the owner of that repo.

#5

Seems like we should at least have a new Team for all the LDMs. Everything else seems to fit into one of the existing teams, though there are a few I’m not sure about.

#6

DMLT doesn’t seem like a completely crazy team for LDMs.

#7

I’ve done the obvious packages. I’ve left the LDMs team-less for now but adding DMLT will be quick.

#8

@frossie pipelines_lsst_io will eventually get added to a team (maybe DM Auxilliaries) but I don’t want to add it yet until pipelines_lsst_io is built by a Jenkins job with the Stack itself.

Also, thanks for explaining the teams! I’ve wanted to add this info to developer.lsst.io.

#9

miniconda2 and miniconda3 are retired eups products that were once used by newinstall.sh. They should not be tagged as part of a release.

#10

I’ve renamed/transfered the miniconda[23] repos -> lsst-dm/legacy-* to be consistent with other retired products.

#11

Perhaps we could prevent this problem in the future by making the Adding a New Package guide more prominent (e.g., moving from Build, Test, Release to Processes)? I only know that page exists because it came up in a search result once.

#12

@kfindeisen Totally. I’m keen to refactor these docs. How we use GitHub, how to create repos in general, how to create stack repos, and how to package TAP packages are all things that need to be documented, but aren’t well described (if at all) in the existing docs.

If someone wants to jump on this project that’s great, but maybe chat with me first since I’ve got some ideas on how to do this.

#13

I’ve moved all of the sims_* repos into the Simulations team.

1 Like
#14

Is it a problem if a package is assigned to more than one of these teams (e.g. Data Management and DM Externals)? I had done that with astshim and just fixed it (at the time I little idea what the teams were used for and didn’t want to lock anybody out).

#15

In that particular case it would probably lead to the package getting two tags when you really only want it to get the 14.0 release tag (and not the external package tag).