Repository navigation
Move this repository upstream to Scientific Python #199
Description
During Scientific Python Developers Summit 2023, another package has taken interest to use and co-contribute to pytest-doctestplus. Given the non-astronomy nature of this package, it would make sense to move this package upstream to https://github.com/scientific-python/ so it could be shared in terms of maintenance and usage across multiple packages (including but not limited to, say, numpy).
Here is the plan:
- @bsipocz would move this repo upstream to Scientific Python.
- @bsipocz would add new maintainers from another package to the repo, in addition to existing maintainers from Astropy. Does this also include RTD, PyPI, and Zenodo access? Have to hash this out...
- @seberg would open a PR to add a feature his package needs. (Though this could happen anytime.)
- Future development and release goes on as usual but now part of Scientific Python org.
- ???
- Profit!!!
From infrastructure tag-up on 2023-05-30 (#199 (comment)), astropy and numpy have agreed on the following terms:
- The license remains the same (BSD modulo the organization name change).
- The current maintainers of pytest-doctestplus will be allowed to continue as full maintainers (provided they still wish to be).
- Admin: @astropy/astropy-project-release-team and @astropy/devops-maintainers
- Write: @astropy/astropy-core-maintainers
- If these are too many people, we can negotiate down to the few who are actually active in pytest-doctestplus currently.
- The workflow should not be altered significantly. We follow common OSS workflow of opening PR from forks, going through code reviews, prohibiting force push to main, and so on.
- Backwards compatibility should be maintained for a while (hopefully with semantic versioning).
Please comment in support or against in this issue.
FWIW, I am in support of this plan, as I presented this as one of the options during the State of Infrastructure in the recent Astropy Coordination Meeting 2023.
| ✔️ | ❌ |
|---|---|
| pllim | |
| mhvk | |
| mwcraig | |
| saimn | |
| bsipocz | |
| seberg (numpy) | |
| hamogu | |
| astrofrog | |
| infrastructure tag-up | |
| dev telecon | |
| CoCo |
xref astropy/astropy-project#118 and https://zenodo.org/record/7948556#.ZHXusXbMKUk
Activity
mhvk commentedon May 30, 2023
Good idea! Note that I think pytest's
NUMBERcould in fact replaceFLOAT_CMP, though on the astropy side it might need adjusting tests, since the tolerance is implicit in the number of digits one uses. But that's a detail on the larger question here.pllim commentedon May 30, 2023
mwcraig commentedon May 30, 2023
Sounds like a good plan to me
bsipocz commentedon May 30, 2023
At this point I think we should keep
FLOAT_CMP, even if it's just an alias toNUMBER. But I'm +1 on ripping the code out and aliasing it, if someone volunteers to do so. Personally, I think there are other fishes to fry first, a lot of missing nice-to-haves.There is just a lot of usage out there, and cleaning up those for the sake of cleaning doesn't make much sense to me.
mhvk commentedon May 30, 2023
Good point. There may well be more
+FLOAT_CMPthan+NUMBER...saimn commentedon May 30, 2023
Sounds great !
pllim commentedon May 30, 2023
I have added a table tracking ✔️ and ❌ that I have seen here so far. Thanks, everyone! 😸
pllim commentedon May 30, 2023
From infrastructure tag-up on 2023-05-30 , astropy and numpy have agreed on the following terms:
For completeness, I will also mention this on the original post.
bsipocz commentedon May 30, 2023
It's weird why the ~30 core maintainers have write access to the infra plugins, isn't that more like an existing oversight here?
Otherwise, I see no issues with bringing over the 4 individuals who are in the admin teams (it has to be a new team though, as afaik cross-org teams are not a thing).
hamogu commentedon May 30, 2023
Personally, I don't care as much who has write access to the new repro, as long as there are maintainers (old or new) who are responsive to PRs. While I technically have write access now, in practice I would open a PR and wait for it to be reviewed by someone.
In my mind, the large number of maintainers is more "anybody can merge a fix of typos in the docs so the maintainers are free to concentrate on the difficult stuff" (like in astropy core, where I might merge a typo fix in a docstring in cosmology, but never a feature that touches code). However, in practice, it seems very rare that that happens (based on looking at recently merged PRs), so there is no evidence that such a broad write access is actually needed.
hamogu commentedon May 30, 2023
I agree though that people who've recently been active in this module and have write access now should be asked to become maintainers in the new repro if they wish to.
astrofrog commentedon May 31, 2023
I am very much in favour of this move. I don't think all core maintainers need to continue being maintainers, maybe just testing infrastructure maintainers and any active maintainers in the last few years?
pllim commentedon May 31, 2023
Yes, I agree with <30 maintainers ported over. 😆 I think even 2-5 would be enough if they are all active.
pllim commentedon Jun 5, 2023
Update from 2023-06-05: 4/5 CoCo members agreed to this (@eteq was absent due to AAS). At this time, there is also no objection from those present at infrastructure tag-up and from dev telecon. So as far as Astropy Project is concerned as a whole, this is a go.
pllim commentedon Jun 6, 2023
Plan from @bsipocz
stefanv commentedon Jun 6, 2023
I think you should be okay to move repos to another org with that org's "permission", but happy to stand by to give you whatever permissions you need along the way to maintain ownership over that repo.
bsipocz commentedon Jun 8, 2023
Step1 is done from the list above with v0.13.0.
Step2 is the CI infrastructure team. We may need to fine-tune and use subteams for the different elements, but atm both @pllim and I are in that team, so can start the moving procedure. Eventually, we need to invite Tom (
astrofrog) and Simon (saimn) to the org. Could you @stefanv or @jarrodmillman do it please? Once they are in the org, the two of us can sort out the team.Step3: @pllim - I can create new repos in the org, so I assume you can too. So maybe it's indeed enough with you astropy owner permissions to get the move done.
Step4: I'll cleanup the CI matrix and add py3.12 compatibility, etc, and tag a 1.0 as a new beginning in the new org.
Step5: ping Sebastian to open his PR :)
jarrodmillman commentedon Jun 8, 2023
I just invited invited Tom (astrofrog) and Simon (saimn) to the CI infrastructure team on the Scientific Python GH org.
pllim commentedon Jun 8, 2023
Step 3 is done! The repo is now https://github.com/scientific-python/pytest-doctestplus 🎉
I'll let the Scientific Python admins figure out the license wordings but it should remain BSD 3-clause. Thanks!
pllim commentedon Jun 8, 2023
I also did Step 5 out of order (didn't read that far down). 😅
bsipocz commentedon Jun 13, 2023
OK, move is done, I'll tag a release soonish, but that's not a blocker for this issue, therefore I'm closing. Thanks @pllim for facilitating.