Le lundi 26 février 2024 à 12:59:47 UTC+1, Dima Pasechnik a écrit :
On Mon, Feb 26, 2024 at 11:36 AM Kwankyu Lee <ekwa...@gmail.com> wrote: On Monday, February 26, 2024 at 6:49:35 PM UTC+9 Dima Pasechnik wrote: >usage 3: Issues that should be fixed as fast as possible > >To me it is rather "issues that should be fixed before the next >release" (or at least it was the way it was supposed to work when we >had trac). This looks better to me as that there is no reason to >release a broken sage. We are now on github Indeed, +1. Issues to be fixed "as fast as possible" are only critical, or less. "blocker" normally means "blocking the release, must be fixed". Then these blocker Issues with no corresponding PRs https://github.com/sagemath/sage/issues/37263 https://github.com/sagemath/sage/issues/36914 forbid the release manager to make a release? I don't know about these particular issues, but a scenario where things are too broken for a release (e.g. docs stopped building) might happen, and did happen in the part. Are you saying that only PRs can block a release? No ! (Catastrophic) *issues* should be able to block a release (see below) But how does one even report a very serious issue, without offering a ready fix? *This is extremely important :* having a way to allow a “plain Sage *user*“ (i. e. someone that “just uses Sage” without being a developer nor having a Github account) is a very important feature; We had this in trac (I can’t rememeber *how*, but I remember starting fiddling with Sage this way), and lost it when switching to Github. Currently, the only way an ordinary user can report an issue is to wail in sage-support and pray for a kind developer soul to create the relevant issue(s). Back to labels : the confusing part is that, as far as I understand, labels are used to qualify both *PRs* (e. g. needs_review, needs work and *issues* (e. g. minor, major, critical, blocker). *Both* uses are necessary. But the wording may need a bit of reworking. In the case of blocker, there are two possible uses : - Issue : the report documents a case where Sage gives a seriuosly wrong answer, never returns or crashes (I’ve seen al these cases). - PR : the fixer or the reviewer report a case where some change in Sagemath *must* be implemented in the next release (or in the next beta : we might distinguish those two cases ?) in order to keep, say, consistency or convention, or allow use of other (present or future) parts of Sage. Similar distinct use cases come to mind for other labels, such as minor or major). Unless there is an alternative to the labels mechanism, we should have at least distinct labels for PR and issue usages. Are you saying one should use other channels of communication for this? (Which is weird, to say the least). No ! (See above…). HTH; -- 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/e4cab63c-e380-4525-b860-93f0842ead82n%40googlegroups.com.
