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
>
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
(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
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
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'
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
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
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
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()
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:
>
>
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
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
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
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
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,
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
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
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
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?
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
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
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
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
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
24 matches
Mail list logo
