Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[David Roe]

We have received messages from several people that the level of discord on
display between Dima and Matthias makes them feel uncomfortable
participating on this email list. To protect the community from this
acrimony, we are for now restricting Dima and Matthias to moderated
contributions on sage-devel.  We are sad in taking this step, and are
continuing to work privately with both Dima and Matthias to resolve this
conflict.
David
for the sage-conduct committee

On Wed, Apr 10, 2024 at 7:30 PM Matthias Koeppe 
wrote:

> Reported.
>
> On Wednesday, April 10, 2024 at 3:39:56 PM UTC-7 Dima Pasechnik wrote:
>
>> On Wed, Apr 10, 2024 at 6:14 PM Matthias Koeppe 
>> wrote:
>>
>>> On Wednesday, April 10, 2024 at 6:49:11 AM UTC-7 julian...@fsfe.org
>>> wrote:
>>>
>>> We have carefully reviewed [...]
>>>
>>> We therefore disagree with characterizing opposing opinions as
>>> “artificial friction”, “hostile demands”, or an “attempt to sabotage”.
>>> Such allegations will have no effect other than to antagonize the other
>>> party. This is not helpful in fostering constructive debate.
>>>
>>>
>>> Julian, please, that's highly inappropriate. I'm not characterizing
>>> opposing *opinions*.
>>>
>>
>> Matthias, you keep characterizing my input into discussions as
>> "persistent abusive conduct", see e.g. your
>> https://github.com/sagemath/sage/pull/36676#issuecomment-2048352139
>>
>> I demand a public apology, and a lift of the block on GitHub.
>> Else Matthias should be banned from SageMath for a while, if not
>> permanently. Enough is enough.
>>
>> Dima
>>
>>
>>> With this terminology I'm describing the modes of existing, persistent,
>>> non-constructive *actions* on these PRs by others.
>>>
>>
>>> These are not "allegations"; what I am describing has been happening in
>>> plain sight, is fully documented, and has been reported to the sage-abuse
>>> and CoCC committees. As you know, some of these have already led to
>>> sanctions by the committees, while I am still waiting for acknowledgment
>>> (and clear actions) regarding numerous reported violations of our code of
>>> conduct (and reviewing code) by the current committee.
>>>
>>> I do understand that the new committee is still learning how to
>>> recognize and handle abuse; it's a complicated and challenging topic to
>>> master. In the meantime, as I have asked the committee in private already,
>>> more thoughtful restraint in issuing public reprimands is necessary.
>>>
>>> --
>>> 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/2bdbf209-edc2-4a0d-9b4c-de1c665d406bn%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/4ec2449a-90cc-479a-be88-723f7f9135cfn%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_nieEkQP%3DZLTv_ZQge%3Dc7%2BD7zbbjuseRK3tRy%2Bakj_-hA%40mail.gmail.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

['tobia...@gmx.de' via sage-devel]

> 4. Please vote -1 on https://github.com/sagemath/sage/pull/36580, 
https://github.com/sagemath/sage/pull/36753, and 
https://github.com/sagemath/sage/pull/37138, which attempt to obstruct the 
modularization project and the mechanism for the distribution on PyPI. 

Please refrain from such unfounded and wrong accusations. The purpose of 
these PRs is to solve concrete problems. If there are conflicts with the 
modularization project, we can discuss these technical questions and try to 
find a solution (perhaps by changing the PR, or by slightly changing the 
design of the modularization distributions). Please also don't use the 
modularization project as a political tool to prevent PR from being merged. 
For example in https://github.com/sagemath/sage/pull/36753 you claim that 
it conflicts with the modularization project (and this is then cited by 
others as the reason for their -1) but so far you have not given a single 
example where the CI or some documented behavior is actually broken (you 
only have given slight change in behavior in an artificial edge case).

I would also kindly ask the developers working on 
https://github.com/sagemath/sage/pull/36676 to not consider the vote on 
this PR as a vote on the question weather we should proceed with the whole 
modularization project. I'm actually a fan of the modularization and would 
like to see it come into reality. But that doesn't mean that one cannot 
question certain design choices in the modularization project. Concerning 
this particular PR, there is no technical need for the addition of these 
`all_xyz` files and multiple different solutions have to be proposed. Such 
technical question should be open for discussion, especially since they 
have not been discussed before (the general program has been discussed on 
the mailing list, but many details of the modularization project have not). 
So please let's try to not load the discussion by unnecessary politics.

On Thursday, April 11, 2024 at 7:30:15 AM UTC+8 Matthias Koeppe wrote:

> Reported.
>
> On Wednesday, April 10, 2024 at 3:39:56 PM UTC-7 Dima Pasechnik wrote:
>
>> On Wed, Apr 10, 2024 at 6:14 PM Matthias Koeppe  
>> wrote:
>>
>>> On Wednesday, April 10, 2024 at 6:49:11 AM UTC-7 julian...@fsfe.org 
>>> wrote:
>>>
>>> We have carefully reviewed [...]
>>>
>>> We therefore disagree with characterizing opposing opinions as 
>>> “artificial friction”, “hostile demands”, or an “attempt to sabotage”.
>>> Such allegations will have no effect other than to antagonize the other 
>>> party. This is not helpful in fostering constructive debate.
>>>
>>>
>>> Julian, please, that's highly inappropriate. I'm not characterizing 
>>> opposing *opinions*.
>>>
>>
>> Matthias, you keep characterizing my input into discussions as 
>> "persistent abusive conduct", see e.g. your
>> https://github.com/sagemath/sage/pull/36676#issuecomment-2048352139
>>
>> I demand a public apology, and a lift of the block on GitHub.
>> Else Matthias should be banned from SageMath for a while, if not 
>> permanently. Enough is enough. 
>>
>> Dima
>>
>>
>>> With this terminology I'm describing the modes of existing, persistent, 
>>> non-constructive *actions* on these PRs by others. 
>>>
>>
>>> These are not "allegations"; what I am describing has been happening in 
>>> plain sight, is fully documented, and has been reported to the sage-abuse 
>>> and CoCC committees. As you know, some of these have already led to 
>>> sanctions by the committees, while I am still waiting for acknowledgment 
>>> (and clear actions) regarding numerous reported violations of our code of 
>>> conduct (and reviewing code) by the current committee.
>>>
>>> I do understand that the new committee is still learning how to 
>>> recognize and handle abuse; it's a complicated and challenging topic to 
>>> master. In the meantime, as I have asked the committee in private already, 
>>> more thoughtful restraint in issuing public reprimands is necessary.
>>>
>>> -- 
>>> 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/2bdbf209-edc2-4a0d-9b4c-de1c665d406bn%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/5d447573-1574-43d4-9127-7852f51acad9n%40googlegroups.com.

Re: [sage-devel] Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Kwankyu Lee]

+1

-- 
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/85d854c0-2537-46e9-a3e6-0502243802edn%40googlegroups.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Matthias Koeppe]

Reported.

On Wednesday, April 10, 2024 at 3:39:56 PM UTC-7 Dima Pasechnik wrote:

> On Wed, Apr 10, 2024 at 6:14 PM Matthias Koeppe  
> wrote:
>
>> On Wednesday, April 10, 2024 at 6:49:11 AM UTC-7 julian...@fsfe.org 
>> wrote:
>>
>> We have carefully reviewed [...]
>>
>> We therefore disagree with characterizing opposing opinions as 
>> “artificial friction”, “hostile demands”, or an “attempt to sabotage”.
>> Such allegations will have no effect other than to antagonize the other 
>> party. This is not helpful in fostering constructive debate.
>>
>>
>> Julian, please, that's highly inappropriate. I'm not characterizing 
>> opposing *opinions*.
>>
>
> Matthias, you keep characterizing my input into discussions as "persistent 
> abusive conduct", see e.g. your
> https://github.com/sagemath/sage/pull/36676#issuecomment-2048352139
>
> I demand a public apology, and a lift of the block on GitHub.
> Else Matthias should be banned from SageMath for a while, if not 
> permanently. Enough is enough. 
>
> Dima
>
>
>> With this terminology I'm describing the modes of existing, persistent, 
>> non-constructive *actions* on these PRs by others. 
>>
>
>> These are not "allegations"; what I am describing has been happening in 
>> plain sight, is fully documented, and has been reported to the sage-abuse 
>> and CoCC committees. As you know, some of these have already led to 
>> sanctions by the committees, while I am still waiting for acknowledgment 
>> (and clear actions) regarding numerous reported violations of our code of 
>> conduct (and reviewing code) by the current committee.
>>
>> I do understand that the new committee is still learning how to recognize 
>> and handle abuse; it's a complicated and challenging topic to master. In 
>> the meantime, as I have asked the committee in private already, more 
>> thoughtful restraint in issuing public reprimands is necessary.
>>
>> -- 
>> 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/2bdbf209-edc2-4a0d-9b4c-de1c665d406bn%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/4ec2449a-90cc-479a-be88-723f7f9135cfn%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote:

On Wed, Apr 10, 2024 at 11:10 PM Matthias Koeppe  
wrote:

On Wednesday, April 10, 2024 at 2:40:18 PM UTC-7 Dima Pasechnik wrote:

There is simply no need to keep the .gitsubmodules -

the only file in the main repo affected by "git submodule update --remote" 
- 
always synchronized, commit-wise, for everyone.


There is. Without doing that, the changes made in the submodule won't take 
effect. 

This is not true.

  git submodule update --remote

will pick up submodules changes just fine.


Necessary reminder that we're discussing, as the subject says, the files 
that control the GitHub workflows and the Codespaces.
What a developer may do on their local machine does not matter.

-- 
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/b178151b-6c80-4a8c-a93d-04fc824f969dn%40googlegroups.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Dima Pasechnik]

On Wed, Apr 10, 2024 at 6:14 PM Matthias Koeppe 
wrote:

> On Wednesday, April 10, 2024 at 6:49:11 AM UTC-7 julian...@fsfe.org wrote:
>
> We have carefully reviewed [...]
>
> We therefore disagree with characterizing opposing opinions as “artificial
> friction”, “hostile demands”, or an “attempt to sabotage”.
> Such allegations will have no effect other than to antagonize the other
> party. This is not helpful in fostering constructive debate.
>
>
> Julian, please, that's highly inappropriate. I'm not characterizing
> opposing *opinions*.
>

Matthias, you keep characterizing my input into discussions as "persistent
abusive conduct", see e.g. your
https://github.com/sagemath/sage/pull/36676#issuecomment-2048352139

I demand a public apology, and a lift of the block on GitHub.
Else Matthias should be banned from SageMath for a while, if not
permanently. Enough is enough.

Dima


> With this terminology I'm describing the modes of existing, persistent,
> non-constructive *actions* on these PRs by others.
>

> These are not "allegations"; what I am describing has been happening in
> plain sight, is fully documented, and has been reported to the sage-abuse
> and CoCC committees. As you know, some of these have already led to
> sanctions by the committees, while I am still waiting for acknowledgment
> (and clear actions) regarding numerous reported violations of our code of
> conduct (and reviewing code) by the current committee.
>
> I do understand that the new committee is still learning how to recognize
> and handle abuse; it's a complicated and challenging topic to master. In
> the meantime, as I have asked the committee in private already, more
> thoughtful restraint in issuing public reprimands is necessary.
>
> --
> 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/2bdbf209-edc2-4a0d-9b4c-de1c665d406bn%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/CAAWYfq3kPjHk8-_b69xesUWXgB51bXH3stkrw1_A%2Bet6c6Pq0Q%40mail.gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On Wed, Apr 10, 2024 at 11:10 PM Matthias Koeppe 
wrote:

> On Wednesday, April 10, 2024 at 2:40:18 PM UTC-7 Dima Pasechnik wrote:
>
> On Wed, Apr 10, 2024 at 9:02 PM Matthias Koeppe 
> wrote:
>
> On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:
>
> On 10 April 2024 19:24:12 CEST, Matthias Koeppe 
> wrote:
> >On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
> >[...] git submodules [...]
> >
> >git submodules are included in a repository by specific commit sha of the
> >submodule repo.
> >So whenever one has to make a change in the submodule repo, one also has
> to
> >commit a change (by a second PR) in the main repo.
> Why a 2nd PR?
>
>
> I just explained it. To update the version (commit sha) of the submodule.
>
>
> Have you ever worked with submodules?
>
>
> Yes, Dima, I have.
>
>
> There is simply no need to keep the .gitsubmodules -
> the only file in the main repo affected by "git submodule update --remote"
> -
> always synchronized, commit-wise, for everyone.
>
>
> There is. Without doing that, the changes made in the submodule won't take
> effect.
>
This is not true.

  git submodule update --remote

will pick up submodules changes just fine.
Read the docs?

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

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

On Wednesday, April 10, 2024 at 2:40:18 PM UTC-7 Dima Pasechnik wrote:

On Wed, Apr 10, 2024 at 9:02 PM Matthias Koeppe  
wrote:

On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:

On 10 April 2024 19:24:12 CEST, Matthias Koeppe  
wrote: 
>On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote: 
>[...] git submodules [...] 
> 
>git submodules are included in a repository by specific commit sha of the 
>submodule repo. 
>So whenever one has to make a change in the submodule repo, one also has 
to 
>commit a change (by a second PR) in the main repo. 
Why a 2nd PR?


I just explained it. To update the version (commit sha) of the submodule.


Have you ever worked with submodules?


Yes, Dima, I have.
 

There is simply no need to keep the .gitsubmodules -
the only file in the main repo affected by "git submodule update --remote" 
- 
always synchronized, commit-wise, for everyone.


There is. Without doing that, the changes made in the submodule won't take 
effect. 
That's the whole point.

-- 
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/56e7ccaa-11de-4013-8a0f-b7cd8965a66an%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On Wed, Apr 10, 2024 at 9:02 PM Matthias Koeppe 
wrote:

> On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:
>
> On 10 April 2024 19:24:12 CEST, Matthias Koeppe 
> wrote:
> >On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
> >
> >[...] git submodules [...]
> >
> >git submodules are included in a repository by specific commit sha of the
> >submodule repo.
> >So whenever one has to make a change in the submodule repo, one also has
> to
> >commit a change (by a second PR) in the main repo.
> Why a 2nd PR?
>
>
> I just explained it. To update the version (commit sha) of the submodule.
>

Have you ever worked with submodules?

There is simply no need to keep the .gitsubmodules -
the only file in the main repo affected by "git submodule update --remote"
-
always synchronized, commit-wise, for everyone.
Yes, it's a bit annoying to have that pesky .gitsubmodules around, and I
can imagine that
git-subtree etc I mentioned are a better alternative.

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

Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals

[Nils Bruin]

Also not that there is plenty of code that, in the course of computation, 
writes into attributes of objects. If you're doing multiple of those it's 
very hard in python to make such a modification atomic. So if an interrupt 
ends up splitting an update, you may leave the system in an inconsistent 
state that could affect future computations. It's a nice aspirational goal 
to have Ctrl-C work decently, but if you want your results with a 
reasonably degree of confidence in correctness, you should probably avoid 
interruptions anyway.

Most code is hopefully written defensively: work on a local copy and only 
in the last bit modify the attribute by a single assignment. That minimizes 
the chance for getting inconsistent states from interrupts, but I don't 
think you'll get it to zero, because of the non-atomicity of multiple 
attribute assignments.

On Wednesday 10 April 2024 at 11:03:13 UTC-7 Vincent Delecroix wrote:

> I do not remember anything specific about solve_mod. Though, there are
> many places in Cython source code where sig_on/sig_off is not handled
> carefully enough (and many that were fixed).
>
> The fact that it is not reproducible is not necessarily a huge problem. 
> However,
> - Could you share the code (as minimal as possible) that provokes this
> on your machine?
> - Do you have the complete (C) trace of the crash? You might need to
> install gdb depending on your setup.
>
> Vincent
>
> On Wed, 10 Apr 2024 at 16:18, Georgi Guninski  wrote:
> >
> > I don't have reproducible testcase, but my pain is that sometimes if I
> > press CTL-C e.g. when solve_mod() is called in a loop, I get SEGV and
> > abort.
> > I suspect besides signals, it is hitting race condition.
> > Is this a known issue?
> >
> > Very long ago there was vulnerability in sendmail, where it did
> > printf() or similar in signal handler and this was documented in the
> > literature.
> >
> > --
> > 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/CAGUWgD_7t9OTNdo6Ovrt%3DJdNqmGJLPGsZHVoJK0mNPQhuz1CKQ%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 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/b7d35f4e-7301-4ac4-8cf1-561ba86493e0n%40googlegroups.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Dima Pasechnik]

On 10 April 2024 21:50:43 CEST, Matthias Koeppe  
wrote:
>On Monday, April 8, 2024 at 5:19:02 PM UTC-7 Dima Pasechnik wrote:
>
>On Mon, Apr 8, 2024 at 7:19 PM Matthias Koeppe  wrote:
>
> You will find the comments in these PRs instructive -- also as 
>illustration for a (long overdue) *discussion about governance and review 
>standards* in the Sage project.
>
>
>*1. Please vote +1 on both https://github.com/sagemath/sage/pull/36561 
> and 
>https://github.com/sagemath/sage/pull/37138 
>* ("Move metadata from 
>setup.cfg to pyproject.toml").
>These are trivial "chore" PRs. They update metadata of our pip-installable 
>packages "sage-conf" and "sagemath-standard" to the latest format.
>These straightforward and appropriately focused PRs have been held back by 
>months by *bundling the review of the PRs with unrelated issues.* I call 
>this "artificial friction"; see the discussion in the PRs. To help overcome 
>this artificial friction, please vote.
>
>
>This is not true - the friction is not artificial. It is due to legitimate 
>concerns of developers who are not interested in
>spending all of their time on ever growing "Sage the distribution", and/or 
>who see little merit in Matthias' sagelib modulalisation
>project, which uses Python features (most of all, namespace packages)
>not universally supported by a number of important tools, such as  Cython 
>and pytest.
>
>Please vote -1 on these two PRs (there are more similar PRs around). This 
>will force Matthias to reconsider his priorities [...]
>
>
>What Dima is describing here is exactly the inappropriate bundling that I 
>have called out.

There seems to be nothing else, short of a project fork, to make Matthias 
reconsider.


> It's a violation of our standards of review.

By calling out for a mass vote you have essentially asked for such a violation.

Otherwise the whole thing about designing PRs by massive voting is a massive 
waste of developers' time, as normal reviewing can be a time-consuming process, 
in particular if the PR concerns a not a very familiar topic.


>
>As majority voting on PRs is our current conflict resolution mechanism: 
>All, please vote.
>
So what exactly are you asking for? For reviews, or for massive violation of 
our reviewing standards?

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/062AA6C5-23E9-4CDC-A74D-D8FA8E1D606E%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:

On 10 April 2024 19:24:12 CEST, Matthias Koeppe  
wrote: 
>On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote: 
> 
>[...] git submodules [...] 
> 
>git submodules are included in a repository by specific commit sha of the 
>submodule repo. 
>So whenever one has to make a change in the submodule repo, one also has 
to 
>commit a change (by a second PR) in the main repo. 
Why a 2nd PR?


I just explained it. To update the version (commit sha) of the submodule.

-- 
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/7e976287-8f5e-4248-b5e9-1601bed1fa6dn%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 19:24:12 CEST, Matthias Koeppe  
wrote:
>On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
>
>[...] git submodules [...]
>
>
>git submodules are included in a repository by specific commit sha of the 
>submodule repo.
>So whenever one has to make a change in the submodule repo, one also has to 
>commit a change (by a second PR) in the main repo. 
Why a 2nd PR? 

>Hence this does not solve anything; it only adds more friction.

Anyway, there are alternatives like git-subrepo 
https://github.com/ingydotnet/git-subrepo
and git-subtree, which are said to be 
much more convenient (myself I only used git-submodule, so this is only what 
others say)
and don't suffer from these real or imaginary problems with git-submodule.

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/C9A68AC0-5474-4A85-9E5C-771CDF803176%40gmail.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Matthias Koeppe]

On Monday, April 8, 2024 at 5:19:02 PM UTC-7 Dima Pasechnik wrote:

On Mon, Apr 8, 2024 at 7:19 PM Matthias Koeppe  wrote:

 You will find the comments in these PRs instructive -- also as 
illustration for a (long overdue) *discussion about governance and review 
standards* in the Sage project.


*1. Please vote +1 on both https://github.com/sagemath/sage/pull/36561 
 and 
https://github.com/sagemath/sage/pull/37138 
* ("Move metadata from 
setup.cfg to pyproject.toml").
These are trivial "chore" PRs. They update metadata of our pip-installable 
packages "sage-conf" and "sagemath-standard" to the latest format.
These straightforward and appropriately focused PRs have been held back by 
months by *bundling the review of the PRs with unrelated issues.* I call 
this "artificial friction"; see the discussion in the PRs. To help overcome 
this artificial friction, please vote.


This is not true - the friction is not artificial. It is due to legitimate 
concerns of developers who are not interested in
spending all of their time on ever growing "Sage the distribution", and/or 
who see little merit in Matthias' sagelib modulalisation
project, which uses Python features (most of all, namespace packages)
not universally supported by a number of important tools, such as  Cython 
and pytest.

Please vote -1 on these two PRs (there are more similar PRs around). This 
will force Matthias to reconsider his priorities [...]


What Dima is describing here is exactly the inappropriate bundling that I 
have called out. It's a violation of our standards of review.

As majority voting on PRs is our current conflict resolution mechanism: 
All, please vote.

-- 
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/402cec70-a7b7-460e-9ed4-fbc1466a5e3bn%40googlegroups.com.

Re: [sage-devel] Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On 10 April 2024 20:23:10 CEST, Matthias Koeppe  
wrote:
>Dima, our project does not have such a policy of not adding standard normal 
>packages. This bundling with your political demand is inappropriate and not 
>welcome here.


Why is it unwelcome?
I explained under what condition I am OK with making this package standard. I 
could have just said NO without any explanation.

It is technical and not political. Political is your " not welcome" remark.



>
>On Wednesday, April 10, 2024 at 11:20:14 AM UTC-7 Dima Pasechnik wrote:
>
>> As in the previous attempt, I am OK with it becoming standard only if it 
>> remains a pip package, a no new "batteries are included".
>>
>> As a matter of fact, there is no point in keeping Python toolchain 
>> packages vendored. They can all be pip packages just as well.
>>
>>
>> On 10 April 2024 05:44:36 CEST, Matthias Koeppe  
>> wrote:
>>
>>> We added python_build as an optional "pip" package (see 
>>> https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
>>>  for 
>>> the terminology),
>>> - 
>>> https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/python_build#spkg-python-build
>>>  (added 
>>> in 2022).
>>>
>>> "python_build" (a.k.a. pypa/build) is the current standard front-end for 
>>> making source distributions and wheels from a Python source tree. It has 
>>> replaced the deprecated practices of calling "setup.py sdist" or "setup.py 
>>> bdist_wheel" directly. We already use it for building the modularized 
>>> distribution packages. Making it a standard package will allow us to 
>>> modernize the build infrastructure (front-end) for the Sage library in the 
>>> Sage distribution.
>>>
>>> I'm proposing to make it a standard package according to the procedures 
>>> in our developer guide. Per our policy, that's a "normal" package, so its 
>>> dependency pyproject_hooks will also be added. The PR is prepared in 
>>> https://github.com/sagemath/sage/pull/37300 
>>>
>>> This is a re-do of my proposal 
>>> https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ 
>>> whose discussion was stalled by commenters bundling it with political 
>>> demands. 
>>>
>>>
>

-- 
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/7C5A20B7-533C-4E75-8DEC-AE985DFBBAA9%40gmail.com.

Re: [sage-devel] Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Matthias Koeppe]

Dima, our project does not have such a policy of not adding standard normal 
packages. This bundling with your political demand is inappropriate and not 
welcome here.

On Wednesday, April 10, 2024 at 11:20:14 AM UTC-7 Dima Pasechnik wrote:

> As in the previous attempt, I am OK with it becoming standard only if it 
> remains a pip package, a no new "batteries are included".
>
> As a matter of fact, there is no point in keeping Python toolchain 
> packages vendored. They can all be pip packages just as well.
>
>
> On 10 April 2024 05:44:36 CEST, Matthias Koeppe  
> wrote:
>
>> We added python_build as an optional "pip" package (see 
>> https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
>>  for 
>> the terminology),
>> - 
>> https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/python_build#spkg-python-build
>>  (added 
>> in 2022).
>>
>> "python_build" (a.k.a. pypa/build) is the current standard front-end for 
>> making source distributions and wheels from a Python source tree. It has 
>> replaced the deprecated practices of calling "setup.py sdist" or "setup.py 
>> bdist_wheel" directly. We already use it for building the modularized 
>> distribution packages. Making it a standard package will allow us to 
>> modernize the build infrastructure (front-end) for the Sage library in the 
>> Sage distribution.
>>
>> I'm proposing to make it a standard package according to the procedures 
>> in our developer guide. Per our policy, that's a "normal" package, so its 
>> dependency pyproject_hooks will also be added. The PR is prepared in 
>> https://github.com/sagemath/sage/pull/37300 
>>
>> This is a re-do of my proposal 
>> https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ 
>> whose discussion was stalled by commenters bundling it with political 
>> demands. 
>>
>>

-- 
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/2e535203-69bf-4347-8f19-09d6721e426fn%40googlegroups.com.

Re: [sage-devel] Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

As in the previous attempt, I am OK with it becoming standard only if it 
remains a pip package, a no new "batteries are included".

As a matter of fact, there is no point in keeping Python toolchain packages 
vendored. They can all be pip packages just as well.

On 10 April 2024 05:44:36 CEST, Matthias Koeppe  
wrote:
>We added python_build as an optional "pip" package (see 
>https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
> for 
>the terminology),
>- 
>https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/python_build#spkg-python-build
> (added 
>in 2022).
>
>"python_build" (a.k.a. pypa/build) is the current standard front-end for 
>making source distributions and wheels from a Python source tree. It has 
>replaced the deprecated practices of calling "setup.py sdist" or "setup.py 
>bdist_wheel" directly. We already use it for building the modularized 
>distribution packages. Making it a standard package will allow us to 
>modernize the build infrastructure (front-end) for the Sage library in the 
>Sage distribution.
>
>I'm proposing to make it a standard package according to the procedures in 
>our developer guide. Per our policy, that's a "normal" package, so its 
>dependency pyproject_hooks will also be added. The PR is prepared 
>in https://github.com/sagemath/sage/pull/37300 
>
>This is a re-do of my proposal 
>https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ whose 
>discussion was stalled by commenters bundling it with political demands. 
>
>-- 
>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/e6b74134-7ed7-4da4-8b41-bebeef5c1f15n%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/4133C84E-1CC6-41FF-9AB8-CCB28BAECF64%40gmail.com.

Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals

[Vincent Delecroix]

I do not remember anything specific about solve_mod. Though, there are
many places in Cython source code where sig_on/sig_off is not handled
carefully enough (and many that were fixed).

The fact that it is not reproducible is not necessarily a huge problem. However,
- Could you share the code (as minimal as possible) that provokes this
on your machine?
- Do you have the complete (C) trace of the crash? You might need to
install gdb depending on your setup.

Vincent

On Wed, 10 Apr 2024 at 16:18, Georgi Guninski  wrote:
>
> I don't have reproducible testcase, but my pain is that sometimes if I
> press CTL-C e.g. when solve_mod() is called in a loop, I get SEGV and
> abort.
> I suspect besides signals, it is hitting race condition.
> Is this a known issue?
>
> Very long ago there was vulnerability in sendmail, where it did
> printf() or similar in signal handler and this was documented in the
> literature.
>
> --
> 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/CAGUWgD_7t9OTNdo6Ovrt%3DJdNqmGJLPGsZHVoJK0mNPQhuz1CKQ%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 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/CAGEwAAkUS4secJzvZJfSVivuqoKwnUUGSjPxi2aUAuTY2MinBw%40mail.gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

On Tuesday, April 9, 2024 at 6:39:00 PM UTC-7 Kwankyu Lee wrote:

How about redefining the meaning of "CI Fix" label:

1. We designate a person to be the CI manager. 
2. For PRs pertaining to the designated directories and files, we add "CI 
Fix" label
3. The CI manager has the right to merge PRs with "CI Fix" label to develop.
4. The old meaning of "CI Fix" label as "immediate fixes" is dropped.
5. Hot fix PRs for breakage of CI also gets "CI Fix" label.


Note that "CI Fix" is intended in particular for fixes to the Sage library 
that make the Lint workflow pass.
Such fixes are still needed and should go through normal review.

-- 
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/8537452a-1c7a-499f-8107-169855d026e7n%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:

[...] git submodules [...]


git submodules are included in a repository by specific commit sha of the 
submodule repo.
So whenever one has to make a change in the submodule repo, one also has to 
commit a change (by a second PR) in the main repo. 
Hence this does not solve anything; it only adds more friction.

git submodules are also well-known to be a developer education nightmare.
I'm pretty sure we don't want to go there as a solution for anything in the 
Sage project.


-- 
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/fa82905b-731c-47c3-ad60-09525a0a4af3n%40googlegroups.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Matthias Koeppe]

On Wednesday, April 10, 2024 at 6:49:11 AM UTC-7 julian...@fsfe.org wrote:

We have carefully reviewed [...]

We therefore disagree with characterizing opposing opinions as “artificial 
friction”, “hostile demands”, or an “attempt to sabotage”.
Such allegations will have no effect other than to antagonize the other 
party. This is not helpful in fostering constructive debate.


Julian, please, that's highly inappropriate. I'm not characterizing 
opposing *opinions*.
With this terminology I'm describing the modes of existing, persistent, 
non-constructive *actions* on these PRs by others.

These are not "allegations"; what I am describing has been happening in 
plain sight, is fully documented, and has been reported to the sage-abuse 
and CoCC committees. As you know, some of these have already led to 
sanctions by the committees, while I am still waiting for acknowledgment 
(and clear actions) regarding numerous reported violations of our code of 
conduct (and reviewing code) by the current committee.

I do understand that the new committee is still learning how to recognize 
and handle abuse; it's a complicated and challenging topic to master. In 
the meantime, as I have asked the committee in private already, more 
thoughtful restraint in issuing public reprimands is necessary.

-- 
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/2bdbf209-edc2-4a0d-9b4c-de1c665d406bn%40googlegroups.com.

Re: [sage-devel] Re: source code tarball?

[John Cremona]

Thanks, that's the page I was expecting.

I think it would be a good idea to have that linked more obviously, but  I
am not able to make a PR right now.

I found a tarball on GitHub on the releases page, so made progress, though
as I reported elsewhere I have not yet been able to build sage from it on
one machine.

John



On Wed, 10 Apr 2024, 15:24 julian...@fsfe.org, 
wrote:

> I guess the idea is that further down on this page, you are told to follow
> the instructions in the README here
> https://github.com/sagemath/sage/#readme which in turn tells you get the
> "sources" from here https://www.sagemath.org/download-source.html.
>
> I agree that this is not terribly intuitive, however, the wikipedia link
> was introduced in
>
> commit 5cddc06a8118d8fb9211fe8232b1183daba9f01f
> Date:   Tue Mar 29 15:11:07 2011 +0100
>
> So it's been there for quite a while but certainly the surroundings have
> been modified quite a bit since then.
>
> If you want to create a PR to change that link, I am happy to give it
> positive review.
>
> julian
>
> On Wednesday, April 10, 2024 at 11:56:23 AM UTC+3 John Cremona wrote:
>
>> In the first line of
>> https://doc.sagemath.org/html/en/installation/source.html#sec-installation-from-sources
>> the words "source code" are a link to the wikipedia page for "source code",
>> which is not very helpful.  I was expecting it to be a link to page shoing
>> where to download a tarball.  I sometimes use the tarball to install from
>> source, instead of using a git clone -- I assume that has not been
>> discontinued?
>>
>> John
>>
> --
> 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/52db9220-62b4-4fc5-ac5a-f77bd040a9b7n%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/CAD0p0K7mnkbqT6MDtLyUZA8sCQ_aOaS2pQaOzXerJqeKxW-4AA%40mail.gmail.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[kcrisman]

Please don't!


+1 for sure

> The modularization project (making pip-installation packages that contain 
portions of the sage library) started years ago with a general consensus of 
the sage community. Matthias led the project and did most of hard works. 
Many others did not care much about the project and still do not feel the 
impact except when encountered with the (annoying) "# needs ..." tags. 
 Matthias is also managing much of the sage build system and the CI (mostly 
testing infrastructure) on github, partly to support the modularization 
project. Many of us would appreciate that.

Also +1 for sure

> Such allegations will have no effect other than to antagonize the other 
party. This is not helpful in fostering constructive debate. Please keep 
this thread to a simple explanation of the issues at hand, so that 
interested community members can make an informed decision on their vote 
(or on whether to vote at all).

+1 to both times this was said (even though I'm violating "issues at hand" 
with this comment)

It's worth noting that "whether to vote at all" is, as typical in Sage, 
mostly being honored by not voting.  Trac was similar - it was often hard 
to get people to review even simple tickets that weren't squarely in 
people's domain of experience within the vast Sage library.  For those of 
us who don't really know that much about .toml files, packaging, or 
modularization, we would like to trust that some roadmap that addresses all 
concerns *in an acceptable, if quite imperfect, compromise* can be come up 
with by those who *do* have expertise in those matters.  

But they'll have to ignore the personal/political matter, hard as it might 
be.  *Even if it's true* that there is "sabotage" or "refusing to assess" 
(which this post remains neutral on), if it is *possible* to interpret a 
code change request as being well-intentioned and helping some aspect of 
packaging, then that should be done.  Until such time as another Sage Days 
*in person* could be held on a topic like packaging, the best operating 
procedure for online-only discussions is to give the most charitable 
possible interpretation to a given code request - and refrain from any 
comments that imply ill will on the part of another, *even if you think 
there is ill will*.  (Then the truly ill willed statements will be clear, 
at least, instead of currently sometimes being themselves ambiguous.)

-- 
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/bb7c57ca-1f3d-4d07-8761-6214a150a179n%40googlegroups.com.

[sage-devel] Re: source code tarball?

[julian...@fsfe.org]

I guess the idea is that further down on this page, you are told to follow 
the instructions in the README here 
https://github.com/sagemath/sage/#readme which in turn tells you get the 
"sources" from here https://www.sagemath.org/download-source.html.

I agree that this is not terribly intuitive, however, the wikipedia link 
was introduced in

commit 5cddc06a8118d8fb9211fe8232b1183daba9f01f
Date:   Tue Mar 29 15:11:07 2011 +0100

So it's been there for quite a while but certainly the surroundings have 
been modified quite a bit since then.

If you want to create a PR to change that link, I am happy to give it 
positive review.

julian

On Wednesday, April 10, 2024 at 11:56:23 AM UTC+3 John Cremona wrote:

> In the first line of 
> https://doc.sagemath.org/html/en/installation/source.html#sec-installation-from-sources
>  
> the words "source code" are a link to the wikipedia page for "source code", 
> which is not very helpful.  I was expecting it to be a link to page shoing 
> where to download a tarball.  I sometimes use the tarball to install from 
> source, instead of using a git clone -- I assume that has not been 
> discontinued?
>
> John
>

-- 
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/52db9220-62b4-4fc5-ac5a-f77bd040a9b7n%40googlegroups.com.

[sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals

[Georgi Guninski]

I don't have reproducible testcase, but my pain is that sometimes if I
press CTL-C e.g. when solve_mod() is called in a loop, I get SEGV and
abort.
I suspect besides signals, it is hitting race condition.
Is this a known issue?

Very long ago there was vulnerability in sendmail, where it did
printf() or similar in signal handler and this was documented in the
literature.

-- 
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/CAGUWgD_7t9OTNdo6Ovrt%3DJdNqmGJLPGsZHVoJK0mNPQhuz1CKQ%40mail.gmail.com.

[sage-devel] Re: Problem with InfinitePolynomialRing

[julian...@fsfe.org]

Hi Martin,

On Tuesday, April 2, 2024 at 3:17:19 PM UTC+3 Martin R wrote:

I tried all day to make sense of the element_constructor of the 
InfinitePolynomialRIng (which uses sage_eval to interpret the repr), but I 
failed.


That string eval is quite curious. I have no clue why it's necessary. 
However, isn't the underlying issue that the symbolic ring has no gens (and 
no ngens, and no gens_dict)?  I have no clue what the correct 
implementation could look like but all these just throwing a RuntimeError 
looks quite wrong to me. Any other implementation seems to improve the 
situation:

sage: class SR_(sage.symbolic.ring.SymbolicRing):
: def gens_dict(self): return {}
:
sage: SR = SR_()
sage: R. = InfinitePolynomialRing(SR)
sage: p = a[0].polynomial()
sage: R(p)
a_0

Alternatively,

sage: class SR_(sage.symbolic.ring.SymbolicRing):
: def gens_dict(self): raise ValueError() # caught by the infinite 
polynomial ring
[...]
sage: R(p)
ValueError: cannot convert a_0 into an element of Infinite polynomial ring 
in a over Symbolic Ring - no conversion into underlying polynomial ring

I'm also no expert when it comes to the symbolic ring. But I'm on Zulip if 
you want to investigate together what's going on.

julian

-- 
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/d5c11f89-8813-44a9-994c-5d7ee0f346d1n%40googlegroups.com.

[sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Nathan Dunfield]

+1: Using the PyPA standard build tools is a good move.

On Tuesday, April 9, 2024 at 10:44:36 PM UTC-5 Matthias Koeppe wrote:

> We added python_build as an optional "pip" package (see 
> https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
>  for 
> the terminology),
> - 
> https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/python_build#spkg-python-build
>  (added 
> in 2022).
>
> "python_build" (a.k.a. pypa/build) is the current standard front-end for 
> making source distributions and wheels from a Python source tree. It has 
> replaced the deprecated practices of calling "setup.py sdist" or "setup.py 
> bdist_wheel" directly. We already use it for building the modularized 
> distribution packages. Making it a standard package will allow us to 
> modernize the build infrastructure (front-end) for the Sage library in the 
> Sage distribution.
>
> I'm proposing to make it a standard package according to the procedures in 
> our developer guide. Per our policy, that's a "normal" package, so its 
> dependency pyproject_hooks will also be added. The PR is prepared in 
> https://github.com/sagemath/sage/pull/37300 
>
> This is a re-do of my proposal 
> https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ whose 
> discussion was stalled by commenters bundling it with political demands. 
>
>

-- 
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/13f7a510-d4e8-4a64-a037-eb0094845a33n%40googlegroups.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[julian...@fsfe.org]

Matthias,

We have carefully reviewed the arguments people have brought for and 
against the disputed PRs and find it credible that both sides have genuine 
concerns. We therefore disagree with characterizing opposing opinions as 
“artificial friction”, “hostile demands”, or an “attempt to sabotage”.
Such allegations will have no effect other than to antagonize the other 
party. This is not helpful in fostering constructive debate. Please keep 
this thread to a simple explanation of the issues at hand, so that 
interested community members can make an informed decision on their vote 
(or on whether to vote at all).

The Code of Conduct Committee

-- 
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/285931f0-7164-471e-b94f-af411517cdcbn%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 03:39:00 CEST, Kwankyu Lee  wrote:
>How about redefining the meaning of "CI Fix" label:
>
>1. We designate a person to be the CI manager. 
>2. For PRs pertaining to the designated directories and files, we add "CI 
>Fix" label
>3. The CI manager has the right to merge PRs with "CI Fix" label to develop.
>4. The old meaning of "CI Fix" label as "immediate fixes" is dropped.
>5. Hot fix PRs for breakage of CI also gets "CI Fix" label.

No, this has a big risk that such a manager will accidentally push non-CI bits, 
and obviously the discipline for not mixing CI and non-CI bits in one commit/PR 
will need to be manually managed.

This is why my proposal to split the repo is much better in this way. 

(One of the mottos of the political party I am forced to set up is "monorepos 
considered harmful", along with "batteries excluded" :-))




>
>?
>
>

-- 
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/2F5FD23C-680E-4FC5-8ECE-69BE08A3F3B0%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 02:04:48 CEST, Matthias Koeppe  
wrote:
>On Tuesday, April 9, 2024 at 4:20:56 PM UTC-7 Dima Pasechnik wrote:
>
>have a CI/sage-distro repo [...] with all that .github/ etc stuff needed 
>for CI, including a part of build/ - and checkout sagelib as a submodule.
>
>
>Also that does not work. Part of the .github/workflows is to run the CI on 
>the pull requests for the Sage library, and the .devcontainer is for making 
>GitHub Codespaces available on the pull requests for the Sage library.

Regarding CI, triggering a git update+CI run on an event in  another repo is 
done via a repository_dispatch hook. 


Indeed, it would be silly if one needed to pollute another repo with your CI 
workflow files.

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/B44D0BAB-7B85-4121-B34E-5851FE72880E%40gmail.com.

[sage-devel] source code tarball?

[John Cremona]

In the first line of
https://doc.sagemath.org/html/en/installation/source.html#sec-installation-from-sources
the words "source code" are a link to the wikipedia page for "source code",
which is not very helpful.  I was expecting it to be a link to page shoing
where to download a tarball.  I sometimes use the tarball to install from
source, instead of using a git clone -- I assume that has not been
discontinued?

John

-- 
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/CAD0p0K6y4OXaeBdJi5juOBDAEKDR11%3D-7m%3DXQp8VYcB-r2xXuw%40mail.gmail.com.

[sage-devel] Re: [sagemath/sage] Restructure `sage.*.all` for modularization, replace relative by absolute imports (PR #36676)

[Dima Pasechnik]

Please whoever is not blocked by the author of this PR, record my -1 vote on 
this.

Yes, this vote has a political element in it.
You want to play politics - let us play it.

Dima

On 10 April 2024 02:40:40 CEST, Tobias Diez  wrote:
>@tobiasdiez requested your review on: sagemath/sage#36676 Restructure 
>`sage.*.all` for modularization, replace relative by absolute imports.
>

-- 
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/FAF996E6-B6EE-411C-93AA-CD18394A3CFF%40gmail.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

['Martin R' via sage-devel]

Please don't!

Martin

On Wednesday 10 April 2024 at 00:39:39 UTC+2 Dima Pasechnik wrote:

> I think I will quit the Sage project as soon as decisions on technical 
> merits of PRs and issues will start to be taken in a nakedly political way.
>
> I am very strongly against any political overtones in  these matters - it 
> reminds me all too well what's wrong is in academia in general.
>
> Dima
>
>
>
>
> On 9 April 2024 11:21:46 CEST, Kwankyu Lee  wrote:
>
>> Hi,
>>
>> Reviewing a PR is a technical work, but voting on a disputed PR has a 
>> political element. So I want to make a political remark concerning most of 
>> the disputed PRs.
>>
>> The modularization project (making pip-installation packages that contain 
>> portions of the sage library) started years ago with a general consensus of 
>> the sage community. Matthias led the project and did most of hard works. 
>> Many others did not care much about the project and still do not feel the 
>> impact except when encountered with the (annoying) "# needs ..." tags.
>>
>> Matthias is also managing much of the sage build system and the CI 
>> (mostly testing infrastructure) on github, partly to support the 
>> modularization project. Many of us would appreciate that.
>>
>> Certainly Matthias is not an appointed dictator ruling the developers, 
>> but I think we should at least acknowledge the leading role of him in the 
>> area of his expertise. On technical discussions on PRs, we should give more 
>> weight on his opinions from his expertise.
>>
>> I hope that you decide your vote by weighing the conflicting arguments on 
>> the issues.
>>
>> Kwankyu
>>
>>

-- 
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/9364a6ee-f5e2-4cdf-ba13-ee8242335145n%40googlegroups.com.