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.
