Just move "usage 2" to a new label. Would be more intuitive and explicit in my opinion.
>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.
Indeed, +1. Issues to be fixed "as fast as possible" are only critical, or less.
"blocker" normally means "blocking the release, must be fixed".
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 githubIndeed, +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 PRsforbid the release manager to make a release?
Or (as I propose) only blocker PRs fixing the "blocker" Issues forbid the release manager to make a release?
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/0638e722-ddb2-4112-a721-7a25c11b5882n%40googlegroups.com.
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 githubIndeed, +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 PRsforbid 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;
But how does one even report a very serious issue, without offering a ready fix?
Le lundi 26 février 2024 à 12:59:47 UTC+1, Dima Pasechnik a écrit :
[ Snip... ]
Are you saying that only PRs can block a release?But how does one even report a very serious issue, without offering a ready fix?Are you saying one should use other channels of communication for this? (Which is weird, to say the least).
*Note :* 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`, 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.
Yes, with a good probability, such a huge breakage will be noticed by Volker, but what if not? Or for quite some time such a breaking issue won't be noticed?Or (as I propose) only blocker PRs fixing the "blocker" Issues forbid the release manager to make a release?--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+...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/0638e722-ddb2-4112-a721-7a25c11b5882n%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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/bb7f9798-9456-424c-80f2-8f863ac5bcb5n%40googlegroups.com.
Anyway, as there are only objections here, I give up.Thanks for opinions.
Dear Kwankyu,
Either you give up because people disagree with you (which is a
problem about yourself) or you feel like your proposal was not given
the credit it should have been (which is a problem with the tone of
the "commenters" e-mails). Or maybe something else. But sending an
e-mail saying that you give up because of objections is neither
helping the discussion nor the technical problem that you pointed out
in your initial e-mail.
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
In that case, 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
(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).
I think that usage (1) is the correct use of "blocker," and usage (3) is not. Usage (2) should have a new name, as Vincent proposes. Failing that, this new use of "blocker" must be documented in https://doc.sagemath.org/html/en/developer/review.html.
On Monday, February 26, 2024 at 4:21:58 PM UTC-8 Kwankyu Lee wrote:On Tuesday, February 27, 2024 at 2:43:18 AM UTC+9 Vincent Delecroix wrote:In that case, let me do a proposal.
Introduce a new label distinct from "blocker" forusage 2: PRs that should be merged temporarily before CI tests runI meant by "merged temporarily" the "CI fixes" in Matthias' explanation:
- 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.
So blocker PRs get the chance to be tested together before the release by the "CI fixes" mechanism. Thus "usage 1" and "usage 2" are connected. Having distinct labels for them does not reflect the connection.I propose (as this discussion is a place to give proposals :-) to give "the chance to be tested together" only to blocker PRs with "positive review". This slightly separates "usage 1" and "usage 2". This proposal was suggested when the "CI fixes" mechanism was introduced, and can be activated easily.
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/001204a7-53fe-43ec-8be6-d2dbdd15b69dn%40googlegroups.com.