Re: [sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
On Sunday, May 12, 2024 at 4:42:42 PM UTC+1 Matthias Koeppe wrote: On Friday, May 10, 2024 at 4:19:14 PM UTC-7 julian...@fsfe.org wrote: If I read your proposal correctly, it is about removing review from changes made by "maintainers" [...] That's right -- for the specified files. Mostly, I am opposed to this because changes to the files you list are not automatically uncontroversial, see the disputed https://github.com/sagemath/sage/pull/37740, https://github.com/sagemath/sage/pull/37387, https://github.com/sagemath/sage/pull/37351, https://github.com/sagemath/sage/pull/36726, https://github.com/sagemath/sage/pull/36697, https://github.com/sagemath/sage/pull/36694, https://github.com/sagemath/sage/pull/36678, (there's probably more.) Well, my proposal only generally noted that "waiting for reviewers to approve a PR and waiting for the Release Manager to merge it adds too much delay and friction." But yes, these "disputes" are certainly part of the friction that my proposal seeks to eliminate by establishing proper governance. But since you bring it up and list these examples, yes, we can certainly have this conversation in more detail. [...] In general, I am not sure about changing the review requirements. I know that having to do several rounds of review can be frustrating. At the same time, I like the idea of having somebody double check things. (I consider waiting for the first round of review a necessary annoyance. What can be really frustrating is waiting for the second round of review. Maybe, there are other ways to improve this, e.g., by encouraging people to set things to "feel free to set to positive review yourself once you addressed these tiny things I brought up in my review.") I have to note that this description would not be a good starting point for a conversation. First of all, it makes me uncomfortable that you are sharing generalities about the PR review process, perhaps as if I needed advice on this from you; what could be the possible purpose of doing so? The topic here is much more specific: namely PRs that make changes to the CI. But more importantly, you are writing this after having just brought up PRs such as "CI Linux: Replace use of pkill" ( https://github.com/sagemath/sage/pull/36726) -- which you as member of the sage-conduct committee are familiar with in detail. In this context, mentioning something like "waiting for the second round of review" as "really frustrating" furthers a mischaracterization of the problem, trivializing a very serious matter. "CI Linux: Replace use of pkill" ( https://github.com/sagemath/sage/pull/36726), more precisely, the discussion (the non-flamewar part of it) which went on there, is an excellent example of CI importance blown out of proportion. It was argued there that certain "minimal configurations" of packages are crucial for Sage development, where in reality no sane users would build Sage on such a super-minimal set of packages. These "minimal configurations" are kept as an excuse for not slimming down Sage the distro to a more meaningful set of packages, e.g. not including largely useless parts such as the gcc compiler. If, as proposed, the governance of the CI part of the Sage the distro is getting split off from Sage the distro, but kept inside Sage proper, it will only make CI more dominant, not less, and lead to more disputes, not less. The CI should be, basically, a downstream quality assurance tool, not the means in itself. It should not dictate what packages Sage should or should not vendor, and what versions of Python etc Sage must support. Dima -- 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/206a5801-dda8-4857-b0ff-3fc915490847n%40googlegroups.com.
Re: [sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
Dear Julian, On Friday, May 10, 2024 at 4:19:14 PM UTC-7 julian...@fsfe.org wrote: If I read your proposal correctly, it is about removing review from changes made by "maintainers" [...] That's right -- for the specified files. Mostly, I am opposed to this because changes to the files you list are not automatically uncontroversial, see the disputed https://github.com/sagemath/sage/pull/37740, https://github.com/sagemath/sage/pull/37387, https://github.com/sagemath/sage/pull/37351, https://github.com/sagemath/sage/pull/36726, https://github.com/sagemath/sage/pull/36697, https://github.com/sagemath/sage/pull/36694, https://github.com/sagemath/sage/pull/36678, (there's probably more.) Well, my proposal only generally noted that "waiting for reviewers to approve a PR and waiting for the Release Manager to merge it adds too much delay and friction." But yes, these "disputes" are certainly part of the friction that my proposal seeks to eliminate by establishing proper governance. But since you bring it up and list these examples, yes, we can certainly have this conversation in more detail. [...] In general, I am not sure about changing the review requirements. I know that having to do several rounds of review can be frustrating. At the same time, I like the idea of having somebody double check things. (I consider waiting for the first round of review a necessary annoyance. What can be really frustrating is waiting for the second round of review. Maybe, there are other ways to improve this, e.g., by encouraging people to set things to "feel free to set to positive review yourself once you addressed these tiny things I brought up in my review.") I have to note that this description would not be a good starting point for a conversation. First of all, it makes me uncomfortable that you are sharing generalities about the PR review process, perhaps as if I needed advice on this from you; what could be the possible purpose of doing so? The topic here is much more specific: namely PRs that make changes to the CI. But more importantly, you are writing this after having just brought up PRs such as "CI Linux: Replace use of pkill" (https://github.com/sagemath/sage/pull/36726) -- which you as member of the sage-conduct committee are familiar with in detail. In this context, mentioning something like "waiting for the second round of review" as "really frustrating" furthers a mischaracterization of the problem, trivializing a very serious matter. Matthias -- 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/a7aeaab2-2106-46c6-9dd6-56e2e0e5dd10n%40googlegroups.com.
[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
On Thursday, May 9, 2024 at 2:18:41 AM UTC-7 Volker Braun wrote: +1 to the general idea of maintainers for distinct subtrees As far as the implementation, I'd rather follow a model where there is a single merge queue at the end (currently me, could be automated when the CI is stricter and developers do not / cannot ignore it any more). [...] Really all you need is to * have a "CI Build & Test" tag whose PR's are merged in before CI runs. * maintainer sets positive review on tickets under his responsibility That would also be fine with me, of course. I've opened https://github.com/sagemath/sage/issues/37971 for it -- 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/227b9298-52ea-48c0-a17d-3576725ceacen%40googlegroups.com.
Re: [sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
Splitting responsibilities for different parts of the codebase is standard operating procedure for every large software project. And monorepo (everything in one git tree) is by now the well-established gold standard for managing the source code, especially for all components where you need versions to be in lock-step. Because it really makes no sense to test different versions of the CI infrastructure against multiple versions of the core business logic and multiple version of the documentation to verify that they really work together. And not everybody is a mathematician and a devops engineer and can write the Japanese documentation. I don't see how it can be confusing to other developers, only the maintainers need to have a grasp of what they are maintaining. If you don't know you can always just open a PR and it will go its usual way. The subsystem maintainer doesn't have to be a single person, can also be a group that manages their own workflow. Really we should focus our effort on the math part, where review by experts in the field is super-important to implement state-of-the-art algorithms. On the other hand, I don't really care how the CI is set up as long as it runs the testsuite. On Saturday, May 11, 2024 at 1:19:14 AM UTC+2 julian...@fsfe.org wrote: Dear Matthias, If I read your proposal correctly, it is about removing review from changes made by "maintainers" and merging things directly into develop without waiting for the Release Manager. Mostly, I am opposed to this because changes to the files you list are not automatically uncontroversial, see the disputed https://github.com/sagemath/sage/pull/37740, https://github.com/sagemath/sage/pull/37387, https://github.com/sagemath/sage/pull/37351, https://github.com/sagemath/sage/pull/36726, https://github.com/sagemath/sage/pull/36697, https://github.com/sagemath/sage/pull/36694, https://github.com/sagemath/sage/pull/36678, (there's probably more.) In general, I am not sure about changing the review requirements. I know that having to do several rounds of review can be frustrating. At the same time, I like the idea of having somebody double check things. (I consider waiting for the first round of review a necessary annoyance. What can be really frustrating is waiting for the second round of review. Maybe, there are other ways to improve this, e.g., by encouraging people to set things to "feel free to set to positive review yourself once you addressed these tiny things I brought up in my review.") I also think it's fairly confusing to have different rules for different parts of the repository. I would not mind at all to use different rules for different repositories within the sagemath organization though. And breaking the sage repository into smaller bits sounds like a good idea to me anyway. (As long as all the src/sage and src/doc stays in one place…) There are some means to reuse workflows in GitHub (I have not checked if they are feasible for us) and one could certainly try to extract some things into shared actions that live elsewhere. Maybe that's an approach that is worth exploring? julian -- 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/b28f918f-7275-49b6-b9c0-ea2ef428c19fn%40googlegroups.com.
Re: [sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
On Friday, May 10, 2024 at 4:19:14 PM UTC-7 julian...@fsfe.org wrote: There are some means to reuse workflows in GitHub That's correct. They are called "reusable workflows", and I use them to provide portability testing to upstream projects of Sage. You can read about them in https://github.com/sagemath/sage/issues/8 (I have not checked if they are feasible for us) and one could certainly try to extract some things into shared actions that live elsewhere. Well, I have checked. No, splitting the repository does not solve the problem. -- 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/4a600f59-5b56-470a-ab40-ad80a5d0a71an%40googlegroups.com.
Re: [sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
Dear Matthias, If I read your proposal correctly, it is about removing review from changes made by "maintainers" and merging things directly into develop without waiting for the Release Manager. Mostly, I am opposed to this because changes to the files you list are not automatically uncontroversial, see the disputed https://github.com/sagemath/sage/pull/37740, https://github.com/sagemath/sage/pull/37387, https://github.com/sagemath/sage/pull/37351, https://github.com/sagemath/sage/pull/36726, https://github.com/sagemath/sage/pull/36697, https://github.com/sagemath/sage/pull/36694, https://github.com/sagemath/sage/pull/36678, (there's probably more.) In general, I am not sure about changing the review requirements. I know that having to do several rounds of review can be frustrating. At the same time, I like the idea of having somebody double check things. (I consider waiting for the first round of review a necessary annoyance. What can be really frustrating is waiting for the second round of review. Maybe, there are other ways to improve this, e.g., by encouraging people to set things to "feel free to set to positive review yourself once you addressed these tiny things I brought up in my review.") I also think it's fairly confusing to have different rules for different parts of the repository. I would not mind at all to use different rules for different repositories within the sagemath organization though. And breaking the sage repository into smaller bits sounds like a good idea to me anyway. (As long as all the src/sage and src/doc stays in one place…) There are some means to reuse workflows in GitHub (I have not checked if they are feasible for us) and one could certainly try to extract some things into shared actions that live elsewhere. Maybe that's an approach that is worth exploring? julian -- 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/2f6cbb89-d77c-492b-94a6-6b9a901d790cn%40googlegroups.com.
Re: [sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
On Wednesday, May 8, 2024 at 12:18:51 PM UTC-7 Dima Pasechnik wrote: 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, I'm pretty sure that Volker and I can figure this out; there's no need to worry about this. and I proposed to spin the CI into a separate repository, as an alternative which simplifies a lot of things. I responded to this already in https://groups.google.com/g/sage-devel/c/dEa3i2Fn3ZY/m/1_43GUDTAAAJ; there's nothing to add to that. -- 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/056adbe1-df6b-4f35-941a-16b06edefc73n%40googlegroups.com.
[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
On Wednesday, May 8, 2024 at 6:51:49 PM UTC-7 Kwankyu Lee wrote: The command "tox -e update_docker_platforms" involves a change of the list of tested platforms. The change become effective when a beta release is made by the release manager, since the docker image files are created only at the release time. So there is no need to merge early the change to the develop branch. On the other hand, is it an unnecessary friction that changes of the list of tested platforms go through the normal review process? Yes, that's part of the friction that I would like to eliminate. The function of merging such platform updates is to get the infrastructure in place that allows us to see whether the release is ready to be made. But for example the last platform update (https://github.com/sagemath/sage/pull/37351) missed the 10.3 release, taking 2 months to get merged. -- 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/c1c8d875-37b0-44f1-8319-4f3e1bba9831n%40googlegroups.com.
[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
+1 to the general idea of maintainers for distinct subtrees As far as the implementation, I'd rather follow a model where there is a single merge queue at the end (currently me, could be automated when the CI is stricter and developers do not / cannot ignore it any more). Otherwise we'll just either have broken releases (untested rebase at the end) or drain my time by having to rebase / retest (takes a long time on the buildbot) / notice than another rebase is needed / rinse and repeat Really all you need is to * have a "CI Build & Test" tag whose PR's are merged in before CI runs. * maintainer sets positive review on tickets under his responsibility On Tuesday, April 9, 2024 at 11:12:00 PM UTC+2 Matthias Koeppe wrote: > Dear Sage developers: > I propose to consider the following governance change for a small part of > the Sage repository: > 1. The directories *.ci, .devcontainer, .github/workflows*. These are > special directories that control the GitHub workflows that run for example > on pull requests and when release tags are pushed. > 2. The files *tox.ini* and *build/bin/write-dockerfile.sh*. They contain > the infrastructure for portability testing of the Sage distribution ( > https://doc.sagemath.org/html/en/developer/portability_testing.html). > > Some of these files are shipped as part of the Sage distribution, but none > of them have any role in the build process or runtime of Sage, and thus > none of them are tested by the Release Manager. > > *Status quo: *All changes to these files go through the normal review > process for Sage PRs; when set to "positive review", Volker merges them > into the next development release. > In the terminology of https://martinfowler.com/articles/ship-show-ask.html > (ht Gonzalo Tornaria), this is the "Ask" model. > > Acknowledgment: I'm grateful to all who have contributed to the review of > my PRs that made changes to these files in the past: thanks for your time > and energy. > > *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. > > *Why the change:* > 1. Changes to these files do not have any effect on the build and runtime > of Sage; > - thus changes to these files do not risk breaking the mathematical > correctness, or the performance of anything in Sage; > - hence there may not be the same need for formal review compared to > changes to the Sage library. > > 2. Our project has a collective interest in smoothly operating development > infrastructure / quality assurance tools; > - but tragedy of the commons; > - more specifically, developing/improving such development tools only pays > off individually for developers with a sufficiently high volume of activity > (cf. > https://github.com/sagemath/sage/graphs/contributors?from=2020-01-01=2024-04-09=c > ); > - there may also be a technical barrier that prevents developers from even > reviewing a PR that makes changes to these files; > - hence, waiting for reviewers to approve a PR and waiting for the Release > Manager to merge it adds too much delay and friction. > > 3. Examples (all PRs authored by me, waiting for review): > - "CI build, doc-build: Run containers explicitly, separate jobs for > pyright, build, modularized tests, long tests" ( > https://github.com/sagemath/sage/pull/36498) waiting for review since Oct > 21, 2023 > - "GH Actions: Build platform-independent wheels of sagemath-environment, > sage-setup, sage-sws2rst for PyPI" ( > https://github.com/sagemath/sage/pull/37099) waiting for review since Feb > 5 > - "CI: Update Linux platforms / runners" waiting for review since Feb 14 > - "GH Actions: Build macOS arm64 wheels" ( > https://github.com/sagemath/sage/pull/37503) waiting for review since Feb > 28 > - "CI Build: Fix "test modularized distributions" ( > https://github.com/sagemath/sage/pull/37750) waiting for review since Apr > 4 > - "dist.yml: Download optional/experimental tarballs for GitHub Release > assets" (https://github.com/sagemath/sage/pull/37762) waiting for review > since Apr 6 > > 4. Non-examples (all PRs authored by me, waiting for review): > - "CI Build: Show segfaults using GitHub annotations" ( > https://github.com/sagemath/sage/pull/37738, waiting for review) -- this > makes changes in sage.doctest, so would continue to be reviewed normally > - "tox.ini: Add environments ruff, ruff-minimal; GH Actions: run > ruff-minimal" (https://github.com/sagemath/sage/pull/37453, waiting for > review) -- this also makes changes in src/tox.ini and src/doc, so would > continue to be reviewed normally > - "src/tox.ini (coverage:run): Set concurrency = multiprocessing,threads" ( > https://github.com/sagemath/sage/pull/37010) -- makes changes in > src/tox.ini, so would continue to be reviewed normally > - "sage -tox -e pyright: Update, speed up, isolate"
[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
On Thursday, May 9, 2024 at 3:25:54 AM UTC+9 Matthias Koeppe 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. The command "tox -e update_docker_platforms" involves a change of the list of tested platforms. The change become effective when a beta release is made by the release manager, since the docker image files are created only at the release time. So there is no need to merge early the change to the develop branch. On the other hand, is it an unnecessary friction that changes of the list of tested platforms go through the normal review process? If the answer is no, then *.devcontainer *and *src/doc/en/developer/portability_platform_table.rst *can be excluded from the CI manager governance. -- 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/569da4a5-af4d-4df4-be36-6092be31e9dcn%40googlegroups.com.
Re: [sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
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 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.
[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
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.
[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
On Wednesday, May 8, 2024 at 6:20:52 AM UTC-7 julian...@fsfe.org wrote: It was a bit unclear to me how your v2 proposal is different from the initial proposal on this sage-devel thread. Maybe it's helpful to clarify that build/bin/write-dockerfile.sh was removed from the proposal and src/doc/en/developer/portability_platform_table.rst was added. Otherwise, it's in essentially unchanged. That's right; as I wrote, "changes brought by the merged https://github.com/sagemath/sage/pull/37841, a clarification, and updated examples". -- 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/20925731-ce57-45c6-80f4-8bd4002eefben%40googlegroups.com.
[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
Hi Matthias, It was a bit unclear to me how your v2 proposal is different from the initial proposal on this sage-devel thread. Maybe it's helpful to clarify that build/bin/write-dockerfile.sh was removed from the proposal and src/doc/en/developer/portability_platform_table.rst was added. Otherwise, it's in essentially unchanged. julian On Monday, May 6, 2024 at 11:56:53 PM UTC+3 Matthias Koeppe wrote: > Dear Sage developers: > > I include an updated proposal below, with changes brought by the merged > https://github.com/sagemath/sage/pull/37841, a clarification, and updated > examples). > I ask everyone to focus the discussion on the specifics of the proposal. > I plan to call a vote on this in a week or so. > > Matthias > > === Proposal (v2) > > I propose a governance change for a small part of the main Sage repository: > 1. The directories *.ci, .devcontainer, .github/workflows*. These are > special directories that control the GitHub workflows that run for example > on pull requests and when release tags are pushed, as well as the Dev > Containers feature on GitHub. > 2. The file *tox.ini*. It contains the infrastructure for portability > testing of the Sage distribution ( > https://doc.sagemath.org/html/en/developer/portability_testing.html). > 3. The file *src/doc/en/developer/portability_platform_table.rst *(which > I update using "tox -e update_docker_platforms"). > > Some of these files are shipped as part of the Sage distribution, but none > of them have any role in the build process or runtime of Sage, and thus > none of them are tested by the Release Manager. > > *Status quo: *All changes to these files go through the normal review > process for Sage PRs; when set to "positive review", Volker merges them > into the next development release. In the terminology of > https://martinfowler.com/articles/ship-show-ask.html (ht Gonzalo > Tornaria), this is the "Ask" model. > > *Acknowledgment:* I'm grateful to all who have contributed to the review > of my PRs that made changes to these files in the past: thanks for your > time and energy. In particular, some of the open PRs listed as examples in > the original post have been merged; thanks, Kwankyu, for reviewing of all > of them! > > *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. > > *Why the change:* > *1.* Changes to these files do not have any effect on the build and > runtime of Sage; > - thus changes to these files do not risk breaking the mathematical > correctness, or the performance of anything in Sage; > - hence there may not be the same need for formal review compared to > changes to the Sage library. > > *2.* Our project has a collective interest in smoothly operating > development infrastructure / quality assurance tools; > - but tragedy of the commons; > - more specifically, developing/improving such development tools only pays > off individually for developers with a sufficiently high volume of activity > (cf. > https://github.com/sagemath/sage/graphs/contributors?from=2020-01-01=2024-04-09=c > ); > - there may also be a technical barrier that prevents developers from even > reviewing a PR that makes changes to these files; > - hence, waiting for reviewers to approve a PR and waiting for the Release > Manager to merge it adds too much delay and friction. > > *Examples* (all PRs authored by me, waiting for review): > - "dist.yml: Download optional/experimental tarballs for GitHub Release > assets" (https://github.com/sagemath/sage/pull/37762) > - "CI: Handle the 'p: CI Fix' label" ( > https://github.com/sagemath/sage/pull/37950) > > *Non-examples* (all PRs authored by me, waiting for review): > - "tox.ini: Add environments ruff, ruff-minimal; GH Actions: run > ruff-minimal" (https://github.com/sagemath/sage/pull/37453) -- this also > makes changes in src/tox.ini and src/doc, so would continue to be reviewed > normally > - "sage -tox -e pyright: Update, speed up, isolate" ( > https://github.com/sagemath/sage/pull/36515) -- makes changes to > pyrightconfig.json and src/tox.ini, so would continue to be reviewed > normally > > -- 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/ad1ab9f3-f788-44f0-b6cd-0b8e59c6831fn%40googlegroups.com.
[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
I propose a governance change for a small part of the main Sage repository: 1. The directories *.ci, .devcontainer, .github/workflows*. These are special directories that control the GitHub workflows that run for example on pull requests and when release tags are pushed, as well as the Dev Containers feature on GitHub. 2. The file *tox.ini*. It contains the infrastructure for portability testing of the Sage distribution ( https://doc.sagemath.org/html/en/developer/portability_testing.html). 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. *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. 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. -- 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/1aed11c1-f721-4a40-9b8d-354e613e99efn%40googlegroups.com.
[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
Dear Sage developers: I include an updated proposal below, with changes brought by the merged https://github.com/sagemath/sage/pull/37841, a clarification, and updated examples). I ask everyone to focus the discussion on the specifics of the proposal. I plan to call a vote on this in a week or so. Matthias === Proposal (v2) I propose a governance change for a small part of the main Sage repository: 1. The directories *.ci, .devcontainer, .github/workflows*. These are special directories that control the GitHub workflows that run for example on pull requests and when release tags are pushed, as well as the Dev Containers feature on GitHub. 2. The file *tox.ini*. It contains the infrastructure for portability testing of the Sage distribution ( https://doc.sagemath.org/html/en/developer/portability_testing.html). 3. The file *src/doc/en/developer/portability_platform_table.rst *(which I update using "tox -e update_docker_platforms"). Some of these files are shipped as part of the Sage distribution, but none of them have any role in the build process or runtime of Sage, and thus none of them are tested by the Release Manager. *Status quo: *All changes to these files go through the normal review process for Sage PRs; when set to "positive review", Volker merges them into the next development release. In the terminology of https://martinfowler.com/articles/ship-show-ask.html (ht Gonzalo Tornaria), this is the "Ask" model. *Acknowledgment:* I'm grateful to all who have contributed to the review of my PRs that made changes to these files in the past: thanks for your time and energy. In particular, some of the open PRs listed as examples in the original post have been merged; thanks, Kwankyu, for reviewing of all of them! *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. *Why the change:* *1.* Changes to these files do not have any effect on the build and runtime of Sage; - thus changes to these files do not risk breaking the mathematical correctness, or the performance of anything in Sage; - hence there may not be the same need for formal review compared to changes to the Sage library. *2.* Our project has a collective interest in smoothly operating development infrastructure / quality assurance tools; - but tragedy of the commons; - more specifically, developing/improving such development tools only pays off individually for developers with a sufficiently high volume of activity (cf. https://github.com/sagemath/sage/graphs/contributors?from=2020-01-01=2024-04-09=c ); - there may also be a technical barrier that prevents developers from even reviewing a PR that makes changes to these files; - hence, waiting for reviewers to approve a PR and waiting for the Release Manager to merge it adds too much delay and friction. *Examples* (all PRs authored by me, waiting for review): - "dist.yml: Download optional/experimental tarballs for GitHub Release assets" (https://github.com/sagemath/sage/pull/37762) - "CI: Handle the 'p: CI Fix' label" (https://github.com/sagemath/sage/pull/37950) *Non-examples* (all PRs authored by me, waiting for review): - "tox.ini: Add environments ruff, ruff-minimal; GH Actions: run ruff-minimal" (https://github.com/sagemath/sage/pull/37453) -- this also makes changes in src/tox.ini and src/doc, so would continue to be reviewed normally - "sage -tox -e pyright: Update, speed up, isolate" ( https://github.com/sagemath/sage/pull/36515) -- makes changes to pyrightconfig.json and src/tox.ini, so would continue to be reviewed normally -- 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/10bafce1-43ad-4d81-8206-5f8404bb176dn%40googlegroups.com.
[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
On Tuesday, April 9, 2024 at 3:36:32 PM UTC-7 Kwankyu Lee wrote: 1. The directories *.ci, .devcontainer, .github/workflows*. These are special directories that control the GitHub workflows that run for example on pull requests and when release tags are pushed. 2. The files *tox.ini* and *build/bin/write-dockerfile.sh*. They contain the infrastructure for portability testing of the Sage distribution ( https://doc.sagemath.org/html/en/developer/portability_testing.html). *build/bin/write-dockerfile.sh* could be moved into *.ci* I'm making this suggested change in https://github.com/sagemath/sage/pull/37841 -- 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/e3e93176-e12f-4a36-a156-d58729980479n%40googlegroups.com.
[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
On Tuesday, April 9, 2024 at 3:36:32 PM UTC-7 Kwankyu Lee wrote: 1. The directories *.ci, .devcontainer, .github/workflows*. These are special directories that control the GitHub workflows that run for example on pull requests and when release tags are pushed. 2. The files *tox.ini* and *build/bin/write-dockerfile.sh*. They contain the infrastructure for portability testing of the Sage distribution ( https://doc.sagemath.org/html/en/developer/portability_testing.html). *build/bin/write-dockerfile.sh* could be moved into *.ci* Yes, that's a plausible change. (But it might also be moved along with the top-level *tox.ini* as part of making sage-bootstrap a pip-installable package; https://github.com/sagemath/sage/issues/31662) -- 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/9d6e0c50-577c-4e7d-a99e-a8a4e9ee78ben%40googlegroups.com.
[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
1. The directories *.ci, .devcontainer, .github/workflows*. These are special directories that control the GitHub workflows that run for example on pull requests and when release tags are pushed. 2. The files *tox.ini* and *build/bin/write-dockerfile.sh*. They contain the infrastructure for portability testing of the Sage distribution ( https://doc.sagemath.org/html/en/developer/portability_testing.html). *build/bin/write-dockerfile.sh* could be moved into *.ci* -- 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/9d23b720-8f2d-41ac-bbcd-62ad2f38c8bcn%40googlegroups.com.
