I've already said while the previous version of this was discussed, is that it's a huge mess to have different commit rights for different parts of the tree, and I proposed to spin the CI into a separate repository, as an alternative which simplifies a lot of things.
Dima On Wed, May 8, 2024 at 7:25 PM Matthias Koeppe <matthiaskoe...@gmail.com> wrote: > > On Monday, May 6, 2024 at 10:49:07 PM UTC-7 Kwankyu Lee wrote: > > I propose a governance change for a small part of the main Sage repository: > 1. The directories .ci, .devcontainer, .github/workflows. [...] > 2. The file tox.ini. [...] > > 3. The file src/doc/en/developer/portability_platform_table.rst (which I > update using "tox -e update_docker_platforms"). > > > I think we should restrict the scope to the files and directories strictly in > the CI infrastructure. Anything under `src/` should be excluded. > > > This file src/doc/en/developer/portability_platform_table.rst is part of the > documentation of the CI infrastructure and needs to be updated (by script) > whenever I make changes to the tested platforms. > > > > Proposed change: All changes to these files are made through PRs. When the PR > is ready, a developer in the Maintainer role directly merges the PR into the > "develop" branch. In other words, switch to the "Show" model for these > changes. > > > I fear that developers in the Maintainer role could conflict in making > changes to the CI-related files, as we suffered in the disputed PRs. > > > I don't share this concern. > > By the way, I documented who is currently in the Maintainer role when I > prepared the NumFOCUS application last month, see > https://github.com/sagemath/sage/wiki/NumFOCUS#q13new-please-list-your-projects-maintainers-ie-anyone-with-write-access-to-the-repository > (I haven't checked if it has changed since.) > > There's certainly a broader governance discussion that we should have at some > point (regarding duties and appointment procedures for the Maintainer role, > the Triage team, and other functions in the project), but I would suggest to > do this in a separate thread. > > So I suggest to have only one Maintainer for those files. As we acknowledge a > certain dictatorship of the release manager, we may have a vote to elect the > CI manager and give him/her a restricted dictatorship and responsibility. > > > This model would also work for me, but I think it's unnecessarily specific. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/e955c1d9-96f5-495d-85a9-9267f5414d3dn%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq3h3f0G4JFxwFt02A%3D55xOLeDcNggWkjfUhWH8SRC3PPA%40mail.gmail.com.
