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.
