On Mon, Feb 26, 2024 at 9:59 PM Matthias Koeppe <matthiaskoe...@gmail.com> wrote:
> On Monday, February 26, 2024 at 9:43:18 AM UTC-8 Vincent Delecroix wrote: > > let me do a proposal. > > Introduce a new label distinct from "blocker" for > > usage 2: PRs that should be merged temporarily before CI tests run > > > For reference, this proposal is the same as > https://github.com/sagemath/sage/issues/37428 > > I don't have a strict objection to it. > > But let me take this opportunity to share a bit of background on this > mechanism, which I introduced in > https://github.com/sagemath/sage/pull/36338, and the design choice to > reuse the "blocker" label for it. > > (So far this workflow feature has only been documented in > https://github.com/sagemath/sage/wiki/Sage-10.2-Release-Tour#open-blocker-prs-are-applied-automatically-in-ci-workflows > and a change to it in > https://github.com/sagemath/sage/wiki/Sage-10.3-Release-Tour#customizing-gh-actions-workflows-in-forked-repositories > ) > > That we use this rather unusual mechanism is, of course, mostly a > workaround for idiosyncracies in our procedures regarding (1) how we use > the Sage repository and (2) how we make releases (this is documented in > https://doc.sagemath.org/html/en/developer/review.html#the-release-process; > but some of it needs updating). > > Some of the relevant facts about our procedures: > - Currently, only the Release Manager (Volker) pushes to the "develop" > branch of our repository, and does so only when development releases > (beta/rc/stable) are tagged. > - Betas are tagged on a roughly weekly cadence (sometimes slower), rcs > sometimes on a faster cadence. > - Outside of the release candidate stage, the priority labels including > "blocker" have no influence on when a PR is merged. > - Within the release candidate stage, the Release Manager will only merge > (positively reviewed) PRs with the "blocker" prority. > - When a merge conflict arises, the Release Manager will set the PR to > "needs work"; developers usually wait for the next development release to > discover and resolve the merge conflict. > > Why I reused the "blocker" priority for the "CI fixes" mechanism: > - *Outside of the release candidate stage,* there was relatively little > use of the "blocker" label, simply because it is of little consequence. > - *Within the release candidate stage,* developers who mark a PR as a > "blocker" so that it be merged in the upcoming stable release need to know > whether their blocker PR will be conflicting with other blockers (= > candidates for merging in the next rc). Having the "blocker" label double > as the "CI fixes" trigger takes care of this. > > I'll note that some of this touches matters of governance of the project > as well, a broader discussion of which would be timely. > A broader discussion on the governance is long overdue. We have a number of pending proposals to vote on, but somehow nobody dares to break the filibuster from certain sides. In particular, the question of allowing (allowing! allowing! - not requiring!) standard packages to be pip packages is pending. We cannot get through a straightforward PR renaming install-requires.txt files to something more meaningful, and standard, as the author keeps coming up with objections to the most reasonable choice, renaming them to requirements.txt (format and semantics of install-requires.txt and requirements.txt - which is the standard name - are pretty much the same). Some users positively review their own PRs, consisting of cherry-picked commits from PRs of other users they declare "disputed", as if it's an acceptable practice. See https://github.com/sagemath/sage/pull/37482 Users get banned from even commenting on some PRs, without any notification. This has to stop, it's not the way to ensure any kind of normality - to the contrary, it's a sure way to hell. E.g. my attempt to comment that the latest meson is 1.3.2 on https://github.com/sagemath/sage/pull/37319 results in "There was a problem submitting your review". WTF, really? If someone wants to ban me, it has to be done directly, not in a such sneaky way. I wanted to comment on https://github.com/sagemath/sage/pull/37482 that it has to be reviewed in a normal way, but no, I can't, just in the same way as on #37319 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/CAAWYfq1HLfZ7WW2Df4eCAnJ-rT1pF8_FDQvzGnpayOOS5dATHA%40mail.gmail.com.
