Re: [sage-devel] Re: Unload "blocker" label

[David Roe]

On Mon, Feb 26, 2024 at 8:06 PM John H Palmieri 
wrote:

> 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.
>

I also agree that usage (2) should get a new name.  How about "CIFix?"
David


> 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" for
>>
>> usage 2: PRs that should be merged temporarily before CI tests run
>>
>>
>> I 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+unsubscr...@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
> 
> .
>

-- 
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/CAChs6_%3DXsP9WQ8oW-KfPDQt4sDA8uxNL9K0MOO%3DBoncBm6OMVQ%40mail.gmail.com.

Re: [sage-devel] Re: Unload "blocker" label

[Matthias Koeppe]

On Monday, February 26, 2024 at 1:59:11 PM UTC-8 Matthias Koeppe wrote:

(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've opened https://github.com/sagemath/sage/pull/37487 with an update of 
the description of the release process. 

-- 
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/ff391aa3-0a99-4093-b121-c18afb40e818n%40googlegroups.com.

Re: [sage-devel] Re: Unload "blocker" label

[John H Palmieri]

(and Tobias also proposed in https://github.com/sagemath/sage/issues/37428)

On Monday, February 26, 2024 at 5:05:56 PM UTC-8 John H Palmieri wrote:

> 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" for
>>
>> usage 2: PRs that should be merged temporarily before CI tests run
>>
>>
>> I 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/667ef622-5c51-4591-b041-1782061dca8bn%40googlegroups.com.

Re: [sage-devel] Re: Unload "blocker" label

[John H Palmieri]

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" for
>
> usage 2: PRs that should be merged temporarily before CI tests run
>
>
> I 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+unsubscr...@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.

Re: [sage-devel] Re: Unload "blocker" label

[Kwankyu Lee]

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" for

usage 2: PRs that should be merged temporarily before CI tests run


I 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7d341d91-3302-4711-b713-7762a650b89bn%40googlegroups.com.

Re: [sage-devel] Re: Unload "blocker" label

[Dima Pasechnik]

On Mon, Feb 26, 2024 at 9:59 PM Matthias Koeppe 
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.

Re: [sage-devel] Re: Unload "blocker" label

[Matthias Koeppe]

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.

-- 
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/f008d28c-ec0c-40a8-91e3-c5f9e618b2e1n%40googlegroups.com.

Re: [sage-devel] Re: Can't compile version 10.2

[Dima Pasechnik]

it's an auto-generated file, to build the interfaces to all the Pari's 
functions - and there are a lot of them.

On 26 February 2024 16:00:40 GMT, Topaze Topaze  wrote:
>Oh, sorry... it seems that a *single* file takes a surprisingly long time 
>to compile (about 30 minutes !) Please forget my request, I will probably 
>remove this message.
>
>-- 
>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/7c78d381-c2e4-4913-9ed6-785437f8a72fn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1F9C9DE6-479E-4A81-A75B-BB142D4E594B%40gmail.com.

Re: [sage-devel] Bug in finding generators of elliptic curves over a quadratic domain

[David Roe]

The problem is in the definition of avoid.  There was an assumption made
that the discriminant would be integral, so
any(q.divides(m) for m in avoid)
has avoid = [1048576/5764801, 8, 28, 49, 7]
If you change the definition of avoid from
avoid = [self._N, self._D] + [P[0].denominator_ideal().norm() for P in
Plist]
to
avoid = [self._N.numerator(), self._N.denominator(), self._D.numerator(),
self._D.denominator()] + [P[0].denominator_ideal().norm() for P in Plist]
I'm guessing that it will fix the problem.

If you're looking for a short-term solution, you could find an integral
model of E:
sage: EE = E.integral_model(); EE
Elliptic Curve defined by y^2 = x^3 + (30*a-45)*x^2 + (-672*a+952)*x over
Number Field in a with defining polynomial x^2 - 2 with a =
1.414213562373095?
sage: EE.gens_quadratic()
[(-18*a + 26 : 18*a - 26 : 1)]

You'll need to find the morphism from E to EE though in order to get the
generators in terms of coordinates for your original curve.
David

On Mon, Feb 26, 2024 at 12:41 PM William Paulsen 
wrote:

> I ran the following code in SageMath 10.2:
>
> sage: K. = QuadraticField(2)
> sage: E = EllipticCurve([0, 60/49*a - 135/49, 0, -576/343*a + 904/343,
> 0]); E
> Elliptic Curve defined by y^2 = x^3 + (60/49*a-135/49)*x^2 +
> (-576/343*a+904/343)*x over Number Field in a with defining polynomial x^2
> - 2 with a = 1.414213562373095?
> sage: E.rank()
> 1
>
> So I know that the elliptic curve is properly defined, and there should be
> a generator. But when I try to find the generator:
>
> sage: E.gens_quadratic()
>
> I get the following error:
> ---
> TypeError Traceback (most recent call last) Cell In [5], line 1 > 1 E.
> gens_quadratic() File
> /ext/sage/10.2/src/sage/schemes/elliptic_curves/ell_number_field.py:4123,
> in EllipticCurve_number_field.gens_quadratic(self, **kwds) 4121 gens1 =
> [iso1(P) for P in EQ1.gens(**kwds)] 4122 gens2 = [iso2(P) for P in EQ2.
> gens(**kwds)] -> 4123 gens = self.saturation(gens1 + gens2, max_prime=2)[0]
> 4124 self.__gens = gens 4125 return gens File
> /ext/sage/10.2/src/sage/schemes/elliptic_curves/ell_number_field.py:4042,
> in EllipticCurve_number_field.saturation(self, points, verbose,
> max_prime, one_prime, odd_primes_only, lower_ht_bound, reg, debug) 4040 if
> verbose: 4041 print("Saturating at p=%s" % p) -> 4042 newPlist, expo =
> saturator.full_p_saturation(Plist, p) 4043 if expo: 4044 if verbose: File
> /ext/sage/10.2/src/sage/schemes/elliptic_curves/saturation.py:281, in
> EllipticCurveSaturator.full_p_saturation(self, Plist, p) 278 if verbose:
> 279 print("Adding {} torsion generators before 
> {}-saturation".format(extra_torsion,p))
> --> 281 res = self.p_saturation(Plist, p) 282 while res: # res is either
> False or (i, newP) 283 exponent += 1 File
> /ext/sage/10.2/src/sage/schemes/elliptic_curves/saturation.py:497, in
> EllipticCurveSaturator.p_saturation(self, Plist, p, sieve) 495 cm_test = E
> .has_rational_cm() and kro(E.cm_discriminant(), p) == -1 496 for q in
> Primes(): --> 497 if any(q.divides(m) for m in avoid): 498 continue 499 if
> cm_test and not p.divides(q-1): File
> /ext/sage/10.2/src/sage/schemes/elliptic_curves/saturation.py:497, in
> (.0) 495 cm_test = E.has_rational_cm() and kro(E.cm_discriminant(),
> p) == -1 496 for q in Primes(): --> 497 if any(q.divides(m) for m in
> avoid): 498 continue 499 if cm_test and not p.divides(q-1): File
> /ext/sage/10.2/src/sage/rings/integer.pyx:4171, in
> sage.rings.integer.Integer.divides() 4169 cdef bint t 4170 cdef Integer
> _n -> 4171 _n = Integer(n) 4172 if mpz_sgn(self.value) == 0: 4173 return
> mpz_sgn(_n.value) == 0 File /ext/sage/10.2/src/sage/rings/integer.pyx:653,
> in sage.rings.integer.Integer.__init__() 651 otmp = getattr(x,
> "_integer_", None) 652 if otmp is not None: --> 653
> set_from_Integer(self, otmp(the_integer_ring)) 654 return 655 File
> /ext/sage/10.2/src/sage/rings/rational.pyx:2969, in
> sage.rings.rational.Rational._integer_() 2967 """ 2968 if not
> mpz_cmp_si(mpq_denref(self.value), 1) == 0: -> 2969 raise TypeError("no
> conversion of this rational to integer") 2970 cdef Integer n =
> Integer.__new__(Integer) 2971 n.set_from_mpz(mpq_numref(self.value))
> TypeError: no conversion of this rational to integer One thing I noticed
> is that this error is referring to Primes().
> This field happens to have class number 1, but there are many quadratic
> domains that have a larger class number, where Primes would be meaningless.
>
> --
> 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/e85cf0d6-b27c-44ed-9e1c-3bbcd6735a6an%40googlegroups.com
> 

Re: [sage-devel] Re: Unload "blocker" label

[Vincent Delecroix]

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

(even though I think that "merged temporarily" would better be clarified)

Vincent

On Mon, 26 Feb 2024 at 18:35, Matthias Koeppe  wrote:
>
> On Monday, February 26, 2024 at 5:31:47 AM UTC-8 Kwankyu Lee wrote:
>
> Anyway, as there are only objections here, I give up.
>
> Thanks for opinions.
>
>
> On Monday, February 26, 2024 at 6:02:41 AM UTC-8 Vincent Delecroix wrote:
>
> 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.
>
>
> Vincent, I think both are unnecessarily harsh readings of "I give up."
>
> I read Kwankyu's post simply as "I am withdrawing my proposal".
>
>
> --
> 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/0857b65d-3e62-49c2-a622-d692d836bce2n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAGEwAAnDbu71CoyQeb%3D%2BGBJY4ak7mFpGLUqgUYUZSGQF4uaGLQ%40mail.gmail.com.

[sage-devel] Bug in finding generators of elliptic curves over a quadratic domain

[William Paulsen]

I ran the following code in SageMath 10.2:

sage: K. = QuadraticField(2)
sage: E = EllipticCurve([0, 60/49*a - 135/49, 0, -576/343*a + 904/343, 0]); 
E
Elliptic Curve defined by y^2 = x^3 + (60/49*a-135/49)*x^2 + 
(-576/343*a+904/343)*x over Number Field in a with defining polynomial x^2 
- 2 with a = 1.414213562373095?
sage: E.rank()
1

So I know that the elliptic curve is properly defined, and there should be 
a generator. But when I try to find the generator:

sage: E.gens_quadratic()

I get the following error: 
--- 
TypeError Traceback (most recent call last) Cell In [5], line 1 > 1 E.
gens_quadratic() File 
/ext/sage/10.2/src/sage/schemes/elliptic_curves/ell_number_field.py:4123, 
in EllipticCurve_number_field.gens_quadratic(self, **kwds) 4121 gens1 = 
[iso1(P) for P in EQ1.gens(**kwds)] 4122 gens2 = [iso2(P) for P in EQ2.gens(
**kwds)] -> 4123 gens = self.saturation(gens1 + gens2, max_prime=2)[0] 4124 
self.__gens = gens 4125 return gens File 
/ext/sage/10.2/src/sage/schemes/elliptic_curves/ell_number_field.py:4042, 
in EllipticCurve_number_field.saturation(self, points, verbose, max_prime, 
one_prime, odd_primes_only, lower_ht_bound, reg, debug) 4040 if verbose: 
4041 print("Saturating at p=%s" % p) -> 4042 newPlist, expo = saturator.
full_p_saturation(Plist, p) 4043 if expo: 4044 if verbose: File 
/ext/sage/10.2/src/sage/schemes/elliptic_curves/saturation.py:281, in 
EllipticCurveSaturator.full_p_saturation(self, Plist, p) 278 if verbose: 279 
print("Adding {} torsion generators before 
{}-saturation".format(extra_torsion,p)) 
--> 281 res = self.p_saturation(Plist, p) 282 while res: # res is either 
False or (i, newP) 283 exponent += 1 File 
/ext/sage/10.2/src/sage/schemes/elliptic_curves/saturation.py:497, in 
EllipticCurveSaturator.p_saturation(self, Plist, p, sieve) 495 cm_test = 
E.has_rational_cm() 
and kro(E.cm_discriminant(), p) == -1 496 for q in Primes(): --> 497 if any(
q.divides(m) for m in avoid): 498 continue 499 if cm_test and not p.
divides(q-1): File 
/ext/sage/10.2/src/sage/schemes/elliptic_curves/saturation.py:497, in 
(.0) 495 cm_test = E.has_rational_cm() and kro(E.cm_discriminant(), 
p) == -1 496 for q in Primes(): --> 497 if any(q.divides(m) for m in 
avoid): 498 continue 499 if cm_test and not p.divides(q-1): File 
/ext/sage/10.2/src/sage/rings/integer.pyx:4171, in 
sage.rings.integer.Integer.divides() 4169 cdef bint t 4170 cdef Integer _n -> 
4171 _n = Integer(n) 4172 if mpz_sgn(self.value) == 0: 4173 return 
mpz_sgn(_n.value) == 0 File /ext/sage/10.2/src/sage/rings/integer.pyx:653, 
in sage.rings.integer.Integer.__init__() 651 otmp = getattr(x, "_integer_", 
None) 652 if otmp is not None: --> 653 set_from_Integer(self, 
otmp(the_integer_ring)) 654 return 655 File 
/ext/sage/10.2/src/sage/rings/rational.pyx:2969, in 
sage.rings.rational.Rational._integer_() 2967 """ 2968 if not 
mpz_cmp_si(mpq_denref(self.value), 1) == 0: -> 2969 raise TypeError("no 
conversion of this rational to integer") 2970 cdef Integer n = 
Integer.__new__(Integer) 2971 n.set_from_mpz(mpq_numref(self.value)) 
TypeError: no conversion of this rational to integer One thing I noticed is 
that this error is referring to Primes().
This field happens to have class number 1, but there are many quadratic 
domains that have a larger class number, where Primes would be meaningless. 

-- 
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/e85cf0d6-b27c-44ed-9e1c-3bbcd6735a6an%40googlegroups.com.

Re: [sage-devel] Re: Unload "blocker" label

[Matthias Koeppe]

On Monday, February 26, 2024 at 5:31:47 AM UTC-8 Kwankyu Lee wrote:

Anyway, as there are only objections here, I give up.

Thanks for opinions.


On Monday, February 26, 2024 at 6:02:41 AM UTC-8 Vincent Delecroix wrote:

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.


Vincent, I think both are unnecessarily harsh readings of "I give up."

I read Kwankyu's post simply as "I am withdrawing my proposal".


-- 
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/0857b65d-3e62-49c2-a622-d692d836bce2n%40googlegroups.com.

[sage-devel] Re: Can't compile version 10.2

[Topaze Topaze]

Oh, sorry... it seems that a *single* file takes a surprisingly long time 
to compile (about 30 minutes !) Please forget my request, I will probably 
remove this message.

-- 
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/7c78d381-c2e4-4913-9ed6-785437f8a72fn%40googlegroups.com.

Re: [sage-devel] Re: Unload "blocker" label

[Vincent Delecroix]

Dear Kwankyu,

Note that everybody who kindly took the time to consider your proposal
responded the same : it seems more consistent to have only two
categories {1, 3} and {2} rather than three (following your
numbering).

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.

Best
Vincent


On Mon, 26 Feb 2024 at 14:31, Kwankyu Lee  wrote:
>
> Anyway, as there are only objections here, I give up.
>
> Thanks for opinions.
>
> --
> 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/6b53b2d5-7d52-479b-8886-50c8f1100637n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAGEwAAkb5PkO7CxwZT8xBJcS3fV9mK4HJiWkdSC5GDd%2BiyPSCA%40mail.gmail.com.

Re: [sage-devel] Re: Unload "blocker" label

[Dima Pasechnik]

On Mon, Feb 26, 2024 at 12:45 PM Emmanuel Charpentier <
emanuel.charpent...@gmail.com> wrote:

>
>
> 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).
>

well, 99.9 % of our users either already have a GitHub account, or can
create one rather easily.



>
> 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+unsubscr...@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
> 
> .
>

-- 
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/CAAWYfq0_%2BJt5pg5zuTArnODeOVRKafwr%2BKCpyjEbj-jfd4oMyQ%40mail.gmail.com.

Re: [sage-devel] Re: Unload "blocker" label

[Kwankyu Lee]

Anyway, as there are only objections here, I give up.

Thanks for opinions.

-- 
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/6b53b2d5-7d52-479b-8886-50c8f1100637n%40googlegroups.com.

Re: [sage-devel] Re: Unload "blocker" label

[Kwankyu Lee]

But how does one even report a very serious issue, without offering a ready 
fix? 


I am proposing to use "critical" label for that purpose. That is why I also 
proposed to remove "critical" labels from old Issues (converted from trac 
tickets). 

-- 
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/d828447f-868f-45ce-8753-f08f5ab07d64n%40googlegroups.com.

Re: [sage-devel] Re: Unload "blocker" label

[Emmanuel Charpentier]

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  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.

Re: [sage-devel] Re: Unload "blocker" label

[Emmanuel Charpentier]

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+unsubscr...@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.

Re: [sage-devel] Re: Unload "blocker" label

[Dima Pasechnik]

On Mon, Feb 26, 2024 at 11:36 AM Kwankyu Lee  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?

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).

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+unsubscr...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq29FJeRF43fG3gDegvQjFuHT%3DNzc0Ryz2k33H2vDSV84A%40mail.gmail.com.

Re: [sage-devel] Re: Unload "blocker" label

[Kwankyu Lee]

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?

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+unsubscr...@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.

Re: [sage-devel] Re: Unload "blocker" label

[Dima Pasechnik]

On 26 February 2024 09:08:08 GMT, Vincent Delecroix <20100.delecr...@gmail.com> 
wrote:
>Hi Kwankyu,
>
>I do not agree with
>
>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".


>
>Best
>Vincent
>
>On Mon, 26 Feb 2024 at 09:17, Kwankyu Lee  wrote:
>>
>>
>>
>> On Monday, February 26, 2024 at 4:46:36 PM UTC+9 tobia...@gmx.de wrote:
>>
>> Just move "usage 2" to a new label. Would be more intuitive and explicit in 
>> my opinion.
>>
>>
>> I am a bit inclined to your opinion, but not sure. Others may argue that 
>> "usage 1" and " usage 2" are better to be combined under one label.
>>
>> Anyway, here I am focusing on the (easy) issue of separating "usage 3" from 
>> the "blocker" label.
>>
>>
>>
>>
>> --
>> 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/609bd8c5-92dd-4c64-8204-a4956517558an%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/BED14EC4-6EB3-4D3A-9EB8-ADADB4165AFA%40gmail.com.

Re: [sage-devel] Re: Unload "blocker" label

[Vincent Delecroix]

Hi Kwankyu,

I do not agree with

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.

Best
Vincent

On Mon, 26 Feb 2024 at 09:17, Kwankyu Lee  wrote:
>
>
>
> On Monday, February 26, 2024 at 4:46:36 PM UTC+9 tobia...@gmx.de wrote:
>
> Just move "usage 2" to a new label. Would be more intuitive and explicit in 
> my opinion.
>
>
> I am a bit inclined to your opinion, but not sure. Others may argue that 
> "usage 1" and " usage 2" are better to be combined under one label.
>
> Anyway, here I am focusing on the (easy) issue of separating "usage 3" from 
> the "blocker" label.
>
>
>
>
> --
> 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/609bd8c5-92dd-4c64-8204-a4956517558an%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAGEwAAnLWEi%2BLJJ51tHJUARrykpe_AiwkMyU3NY_TTt_j07C4A%40mail.gmail.com.

[sage-devel] Re: Unload "blocker" label

[Kwankyu Lee]

On Monday, February 26, 2024 at 4:46:36 PM UTC+9 tobia...@gmx.de wrote:

Just move "usage 2" to a new label. Would be more intuitive and explicit in 
my opinion.


I am a bit inclined to your opinion, but not sure. Others may argue that 
"usage 1" and " usage 2" are better to be combined under one label.

Anyway, here I am focusing on the (easy) issue of separating "usage 3" from 
the "blocker" label. 


 

-- 
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/609bd8c5-92dd-4c64-8204-a4956517558an%40googlegroups.com.