date:20240308

Re: [sage-devel] VOTE: Use "CI Fix" label for merging into continuous integration runs

2024-03-08 Thread David Lowry-Duda

- DLD

On 03:43 Mon 04 Mar 2024, David Roe wrote:

The following proposal has been made several times the last few weeks: in
PR #37428 , in this thread
and then in this
thread . It is
orthogonal to the ongoing vote in this thread
. With no further
discussion, I'm calling a vote.

*Background*

Starting in Sage 10.2, PRs with the Blocker label have been merged into all
other PRs before running CI; see the changelog

and this post
for
more details. This has led to disagreements about whether this label
should be applied.

*Proposal*
We use "CI Fix" rather than Blocker to determine whether an open PR should
be merged before running CI. Blocker will retain its previous meaning of a
PR that should be merged before the next release is finished. The process
below describes how to resolve disagreements about whether the "CI Fix"
label should be applied.
a. Only PRs with positive review should be marked with the "CI Fix" label.
This should be done if both author and reviewer agree that it is
appropriate, and a rationale should be given in a comment on the ticket.
b. If a PR becomes disputed (as described in this proposal
), the "CI Fix"
status can be voted on separately upon request; otherwise it should be
applied if and only if positive review is applied.

Voting will be open until Wednesday, March 13.
David

--
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_mYLUWXMU6AZKJGPKd2oz0AC_qAUjnGoD9Q9yixzNBC2w%40mail.gmail.com.

--
David Lowry-Duda

Re: [sage-devel] VOTE: disputed PRs

2024-03-08 Thread David Lowry-Duda

- DLD

On 03:23 Mon 04 Mar 2024, David Roe wrote:

With no further discussion on this thread
, I'm calling a vote
on a new process for resolving disagreements on a PR.

*Proposal*
It is now allowed to vote on disputed PRs directly on Github rather than
bringing them to sage-devel. Working things out amicably is preferable,
and anyone is welcome to ask on sage-devel for more eyes on a PR. If you
notice a serious issue with a PR, it is acceptable to change it to Needs
Work (and make a comment!) as an initial step, but if the author or
reviewer do not agree then process below should be followed instead. This
process is intended as a lower-intensity method for resolving
disagreements, and full votes on sage-devel override the process described
below.
a. When there is disagreement about whether a PR should be merged, anyone
may mark a PR as disputed.
b. There is no scheduled vote, but rather an ongoing poll based on opinions
expressed by developers on the PR (these opinions can be expressed via
previous positive reviews or explicit comments giving approval). The PR
author is presumed to vote in favor; if they give up or no longer favor the
PR they have the right to close the PR overall without any further voting.
c. If the total number of positive votes is at least twice the number of
negative votes, anyone involved may set the status to *positive review*; if
the total number of positive votes is less than twice the number of
negative votes, anyone involved may set the status to *needs review*. When
either of these actions is taken, the person changing the status must list
the people they are counting as positive and negative votes in a comment
using @ mentions.
d. The final decision on merging a disputed PR remains with the release
manager, and we encourage the release manager to give enough time for
everyone to express an opinion.

Voting will be open until Wednesday, March 13.
David

--
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_n4az3_s16E%3DANOv_o%2B0SvavHwnpqKWYuOznGWTJoXqEg%40mail.gmail.com.

--
David Lowry-Duda

Re: [sage-devel] Re: Labels and Reviewing

2024-03-08 Thread David Roe

Dear Sage developers,
Dima is correct that there are several developers who have blocked each
other.  The Sage Code of Conduct Committee is aware of several cases and is
working on resolving them.  We believe both that the presence of these
blocks is harming the Sage project, and that it can be appropriate to block
another user.  In an extreme example, if one user "A" was stalking or
harassing another "B", it would absolutely be appropriate for B to block A.
Any resulting harm to the project is completely the responsibility of A in
such a situation. We are not saying that this situation applies for any of
the existing blocks, but there will certainly be less extreme cases in
which blocking remains appropriate.

In any case, the committee asks that anyone affected by blocking to please
channel their understandable frustration towards patiently working with us
to constructively resolve the current blocks individually and voluntarily.
We will continue to work toward addressing the underlying reasons
(revisions to the code of conduct, recruiting new members, new policies on
labels and reviewing, additional actions on github and in private).

Thanks,
David
for the Sage Code of Conduct Committee

On Fri, Mar 8, 2024 at 9:30 AM Dima Pasechnik  wrote:

>
>
> On 8 March 2024 14:11:41 GMT, 'Martin R' via sage-devel <
> sage-devel@googlegroups.com> wrote:
> >I don't know exactly what case of blocking you have in mind,
>
> on GitHub you can block a user - such a block prevents the blocked user
> from commenting and changing the status of your PRs and issues.
>
> Currently there are a few Sage team members blocking each other.
> I have made our CoC committee aware of this fact, but they are in no rush
> to rule on it, it seems.
>

-- 
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_%3DOQMThbcJz5o%3D-X%3D-kmOrm%3DJJraC%3Dm%2BsJw7_CrAY4Nqw%40mail.gmail.com.

Re: [sage-devel] Re: Labels and Reviewing

2024-03-08 Thread Dima Pasechnik




On 8 March 2024 14:11:41 GMT, 'Martin R' via sage-devel 
 wrote:
>I don't know exactly what case of blocking you have in mind,

on GitHub you can block a user - such a block prevents the blocked user from 
commenting and changing the status of your PRs and issues.

Currently there are a few Sage team members blocking each other.
I have made our CoC committee aware of this fact, but they are in no rush to 
rule on it, it seems.



>  but I'm going 
>to be bold and state that blocking among fellow developers (this is not 
>about private messages, right?) cannot really be a solution, in my opinion:
>
>* either there has been a substantial breach of conduct, in which case I 
>think the person cannot be part of sagemath anymore,
>* or otherwise, there shouldn't be a reason to block.
>
>I hope that we are talking about the empty set.
>
>Martin
>
>On Friday 8 March 2024 at 10:22:30 UTC+1 Dima Pasechnik wrote:
>
>> On Thu, Mar 7, 2024 at 8:39 PM David Roe  wrote:
>>
>>> Addressing a comment from Travis 
>>>  on 
>>> the voting thread:
>>>
>>> "but might want to consider cases when its 2 vs 1 as requiring at least 
>>> one other person involved. (Sorry for being late to realize this.)"
>>>
>>> This border case was actually one of the reasons that I suggested a 2 to 
>>> 1 threshold.  I think that if a single objector thinks that a PR should not 
>>> proceed and the author and reviewer both think it should, the onus should 
>>> be on the objector to find other developers who share their objections.
>>>
>>
>> As long as the issue of GitHub blocks is not resolved, this issue is moot. 
>> A developer can block their opponents
>> on GitHub to make sure there is not enough opposition to their PRs.
>>
>> David
>>>
>>> On Wed, Feb 28, 2024 at 10:53 AM Dima Pasechnik  wrote:
>>>


 On Wed, Feb 28, 2024 at 11:29 AM Giacomo Pope  
 wrote:

> Apologies for the basic question in this thread, but recently I have 
> seen lots of conversation about the different labels and I want to 
> clarify 
> something for myself.
>
> In the past few PR I have made for Sage, randomised testing has 
> uncovered (usually) trivial bugs. I then write new PRs to fix these bugs.
>
> If there is code causing CI failure in random testing, should I mark 
> the fix for this as a "blocker", even if the chance of this failure is 
> small? I don't want to be melodramatic in my PR for fixes but I also want 
> to make sure I'm labelling things as expected,
>

 I don't think we ever tag anything but most onerous maths bugs as 
 blockers
 (e.g. we have a plenty of outstanding symbolic integration bugs).
 That is, unless it's absolutely Earth-shuttering, don't use "blocker".

 Dima
  

>
> On Wednesday, February 28, 2024 at 6:08:20 AM UTC David Roe wrote:
>
>> On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:
>>
>>> Thank you for making progress on these urgent issues. I suggest the 
>>> following:
>>>
>>> 1. Open two other new threads, each of which is for voting on each 
>>> proposal. 
>>> 2. On a proposal, it should be clear that *a positive vote (+1) is 
>>> for the whole proposal,* and if one is negative to any part of the 
>>> proposal, (s)he should give a negative vote (-1).  
>>>
>>
>> Voting threads seem reasonable.  I'll wait a day or two to see if 
>> people have any final comments before voting.
>>  
>>
>>> 3. A proposal is accepted if the number of positive votes is at least 
>>> twice of the number of the negative votes.
>>>
>>
>> Despite the fact that we're asking for this threshold in voting on a 
>> PR, the standard for votes on proposals on sage-devel is just a plain 
>> majority (though of course I hope that we can come to a 2-1 consensus!).
>>
>> A minor suggestion for Proposal 2: for the label to be readable, I 
>>> suggest "CI fix" for the name of the label (a blank between words). 
>>>
>>
>> I'm happy to adjust the label to be "CI fix."
>>  
>>
>>> We may use this thread to get more comments on the Proposals before 
>>> opening voting threads.
>>>
>>> -- 
>>> 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/554961a0-4ace-4317-bfcf-55b6a128bcden%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>> -- 
> You received this message because you are subscribed to the Google 
>

Re: [sage-devel] Re: Labels and Reviewing

2024-03-08 Thread 'Martin R' via sage-devel

I don't know exactly what case of blocking you have in mind, but I'm going 
to be bold and state that blocking among fellow developers (this is not 
about private messages, right?) cannot really be a solution, in my opinion:

* either there has been a substantial breach of conduct, in which case I 
think the person cannot be part of sagemath anymore,
* or otherwise, there shouldn't be a reason to block.

I hope that we are talking about the empty set.

Martin

On Friday 8 March 2024 at 10:22:30 UTC+1 Dima Pasechnik wrote:

> On Thu, Mar 7, 2024 at 8:39 PM David Roe  wrote:
>
>> Addressing a comment from Travis 
>>  on 
>> the voting thread:
>>
>> "but might want to consider cases when its 2 vs 1 as requiring at least 
>> one other person involved. (Sorry for being late to realize this.)"
>>
>> This border case was actually one of the reasons that I suggested a 2 to 
>> 1 threshold.  I think that if a single objector thinks that a PR should not 
>> proceed and the author and reviewer both think it should, the onus should 
>> be on the objector to find other developers who share their objections.
>>
>
> As long as the issue of GitHub blocks is not resolved, this issue is moot. 
> A developer can block their opponents
> on GitHub to make sure there is not enough opposition to their PRs.
>
> David
>>
>> On Wed, Feb 28, 2024 at 10:53 AM Dima Pasechnik  wrote:
>>
>>>
>>>
>>> On Wed, Feb 28, 2024 at 11:29 AM Giacomo Pope  
>>> wrote:
>>>
 Apologies for the basic question in this thread, but recently I have 
 seen lots of conversation about the different labels and I want to clarify 
 something for myself.

 In the past few PR I have made for Sage, randomised testing has 
 uncovered (usually) trivial bugs. I then write new PRs to fix these bugs.

 If there is code causing CI failure in random testing, should I mark 
 the fix for this as a "blocker", even if the chance of this failure is 
 small? I don't want to be melodramatic in my PR for fixes but I also want 
 to make sure I'm labelling things as expected,

>>>
>>> I don't think we ever tag anything but most onerous maths bugs as 
>>> blockers
>>> (e.g. we have a plenty of outstanding symbolic integration bugs).
>>> That is, unless it's absolutely Earth-shuttering, don't use "blocker".
>>>
>>> Dima
>>>  
>>>

 On Wednesday, February 28, 2024 at 6:08:20 AM UTC David Roe wrote:

> On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:
>
>> Thank you for making progress on these urgent issues. I suggest the 
>> following:
>>
>> 1. Open two other new threads, each of which is for voting on each 
>> proposal. 
>> 2. On a proposal, it should be clear that *a positive vote (+1) is 
>> for the whole proposal,* and if one is negative to any part of the 
>> proposal, (s)he should give a negative vote (-1).  
>>
>
> Voting threads seem reasonable.  I'll wait a day or two to see if 
> people have any final comments before voting.
>  
>
>> 3. A proposal is accepted if the number of positive votes is at least 
>> twice of the number of the negative votes.
>>
>
> Despite the fact that we're asking for this threshold in voting on a 
> PR, the standard for votes on proposals on sage-devel is just a plain 
> majority (though of course I hope that we can come to a 2-1 consensus!).
>
> A minor suggestion for Proposal 2: for the label to be readable, I 
>> suggest "CI fix" for the name of the label (a blank between words). 
>>
>
> I'm happy to adjust the label to be "CI fix."
>  
>
>> We may use this thread to get more comments on the Proposals before 
>> opening voting threads.
>>
>> -- 
>> 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/554961a0-4ace-4317-bfcf-55b6a128bcden%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/b84b22d2-9b57-460c-9f8d-5f8ebe2f982en%40googlegroups.com
  
 
 .

>>> -- 
>>> You received this

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

2024-03-08 Thread Giacomo Pope

As a small update, the repository now contains code to

- perform arithmetic for
  - the imaginary model (ramified, one point at infinity) for all cases
  - the real model (split, two points at infinity) for all cases
  - the real model (inert, zero points at infinity) for even genus
  Which allows us to do "as much" as Magma does for Jacobians of 
hyperellipticc curves from the perspective of arithmetic. 

My current "test" for the arithmetic is that D - D = 0 for all cases, that 
jacobian_order * D = zero and that order_from_multiple(D) works. If people 
have other ideas for tests, please let me know. Of course at the moment 
these tests are over finite fields but you can reasonable use other fields 
(as Sabrina's message shows) but I am less sure about how to do randomised 
testing here.

- We also have a function which can randomly (but not uniformly) sample 
elements of the Jacobian for all the cases.
- We can compute the order of the Jacobian from the frob. polynomial and 
using the arithmetic and in-build `order_from_multiple` then find the order 
of divisors

I think the next thing to do is to look at isomorphisms and maybe even 
isogenies (Richelot only for genus two perhaps?)

If you are interested in this area and want to contribute, then I think 
fleshing out the code in this repo will be easier during these early stages 
and once it feels complete we can look at replacing the current code in 
sagemath with this newer version.

On Thursday, March 7, 2024 at 9:40:58 PM UTC Sabrina Kunzweiler wrote:

> Thanks for mentioning the related discussion. We checked that in the new 
> implementation in Giacomo's repository, this issue is solved. 
>
> In the example that was given in the chat, we obtain the following output:
> ```
> sage: R. = QQ[]
> sage: f = 144*x^6 - 240*x^5 + 148*x^4 + 16*x^3 - 16*x^2 - 4*x + 1
> sage: H = HyperellipticCurveNew(f)
> sage: J = Jacobian(H)
> sage: P = J(H([0,1]))-J(H([0,-1]))
> sage: (5*P).is_zero()
> False
> sage: 5*P
> (1, 0 : 2)
> ```
> Here, this means $$ 5 P = (1:12:0) - (1:-12:0) $$ which coincides with the 
> result from magma. 
>
>
> Kwankyu Lee schrieb am Donnerstag, 7. März 2024 um 05:44:33 UTC+1:
>
>> It's still here: https://github.com/sagemath/sage/issues/32024
>
>

-- 
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/16695996-c9bc-4a08-a1a4-37179e7a8956n%40googlegroups.com.

Re: [sage-devel] Re: Labels and Reviewing

2024-03-08 Thread Dima Pasechnik

On Thu, Mar 7, 2024 at 8:39 PM David Roe  wrote:

> Addressing a comment from Travis
>  on
> the voting thread:
>
> "but might want to consider cases when its 2 vs 1 as requiring at least
> one other person involved. (Sorry for being late to realize this.)"
>
> This border case was actually one of the reasons that I suggested a 2 to 1
> threshold.  I think that if a single objector thinks that a PR should not
> proceed and the author and reviewer both think it should, the onus should
> be on the objector to find other developers who share their objections.
>

As long as the issue of GitHub blocks is not resolved, this issue is moot.
A developer can block their opponents
on GitHub to make sure there is not enough opposition to their PRs.

David
>
> On Wed, Feb 28, 2024 at 10:53 AM Dima Pasechnik  wrote:
>
>>
>>
>> On Wed, Feb 28, 2024 at 11:29 AM Giacomo Pope 
>> wrote:
>>
>>> Apologies for the basic question in this thread, but recently I have
>>> seen lots of conversation about the different labels and I want to clarify
>>> something for myself.
>>>
>>> In the past few PR I have made for Sage, randomised testing has
>>> uncovered (usually) trivial bugs. I then write new PRs to fix these bugs.
>>>
>>> If there is code causing CI failure in random testing, should I mark the
>>> fix for this as a "blocker", even if the chance of this failure is small? I
>>> don't want to be melodramatic in my PR for fixes but I also want to make
>>> sure I'm labelling things as expected,
>>>
>>
>> I don't think we ever tag anything but most onerous maths bugs as blockers
>> (e.g. we have a plenty of outstanding symbolic integration bugs).
>> That is, unless it's absolutely Earth-shuttering, don't use "blocker".
>>
>> Dima
>>
>>
>>>
>>> On Wednesday, February 28, 2024 at 6:08:20 AM UTC David Roe wrote:
>>>
 On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:

> Thank you for making progress on these urgent issues. I suggest the
> following:
>
> 1. Open two other new threads, each of which is for voting on each
> proposal.
> 2. On a proposal, it should be clear that *a positive vote (+1) is
> for the whole proposal,* and if one is negative to any part of the
> proposal, (s)he should give a negative vote (-1).
>

 Voting threads seem reasonable.  I'll wait a day or two to see if
 people have any final comments before voting.


> 3. A proposal is accepted if the number of positive votes is at least
> twice of the number of the negative votes.
>

 Despite the fact that we're asking for this threshold in voting on a
 PR, the standard for votes on proposals on sage-devel is just a plain
 majority (though of course I hope that we can come to a 2-1 consensus!).

 A minor suggestion for Proposal 2: for the label to be readable, I
> suggest "CI fix" for the name of the label (a blank between words).
>

 I'm happy to adjust the label to be "CI fix."


> We may use this thread to get more comments on the Proposals before
> opening voting threads.
>
> --
> 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/554961a0-4ace-4317-bfcf-55b6a128bcden%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/b84b22d2-9b57-460c-9f8d-5f8ebe2f982en%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/CAAWYfq2eMM%3DzUHCZ_dpfDvxattotQmaD-0kht6J8ZxCL9K005w%40mail.gmail.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

Re: [sage-devel] VOTE: Use "CI Fix" label for merging into continuous integration runs

Re: [sage-devel] VOTE: disputed PRs

Re: [sage-devel] Re: Labels and Reviewing

Re: [sage-devel] Re: Labels and Reviewing

Re: [sage-devel] Re: Labels and Reviewing

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

Re: [sage-devel] Re: Labels and Reviewing

7 matches

Site Navigation

Mail list logo

Footer information