Re: [sage-devel] Re: Unable to build sage-10.2 on Ubuntu 22.04 WSL

[Gaurish Korpal]

Thank you, Dima! It was indeed due to an accidental allocation of a
significant portion of RAM to the integrated graphics.

On Wed, Jan 10, 2024 at 11:46 PM Dima Pasechnik  wrote:

> Hi,
> you need  to give your WSL more RAM.
> Otherwise big C++ compilations don't go through.
>
>
> On Thursday, January 11, 2024 at 6:44:14 AM UTC gko...@math.arizona.edu
> wrote:
>
>> Hello,
>>
>> I'm trying to build Sage 10.2 from source in Ubuntu 22.04 WSL by following
>> https://doc.sagemath.org/html/en/installation/source.html
>> but I get errors when it tries to compile the scipy-1.11.3 package.
>>
>> I have attached config.log and scipy-1.11.3.log files for the full logs.
>> Here are the steps I took:
>>
>> 1. Created the directory ~/sage/
>> 2. Downloaded source file and saved it in ~/sage/
>> 3. tar xf sage-10.2.tar.gz
>> 4. cd sage-10.2/
>> 5. export PATH=/usr/sbin/:/sbin/:/bin/:/usr/lib/wsl/lib/
>> 6. export MAKE="make -j4 -l5.5"
>> 7. export V=0
>> 8. ./configure --disable-editable
>> --prefix=/home/gkorpal/sage/sage-10.2/local
>> 9. make
>>
>> Any help would be most welcome.
>>
>> Sincerely,
>> Gaurish
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/W4gMvzNaPs0/unsubscribe.
> To unsubscribe from this group and all its topics, 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/904645c5-7d43-4d0e-8088-32129dbadfbdn%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/CAKjDUKcNdE2AJ2Lt%3DBRks%2BogSLrr43sXxW6bEd5O7FLcDC2GrQ%40mail.gmail.com.

[sage-devel] Re: Unable to build sage-10.2 on Ubuntu 22.04 WSL

[Dima Pasechnik]

Hi,
you need  to give your WSL more RAM.
Otherwise big C++ compilations don't go through.


On Thursday, January 11, 2024 at 6:44:14 AM UTC gko...@math.arizona.edu 
wrote:

> Hello,
>
> I'm trying to build Sage 10.2 from source in Ubuntu 22.04 WSL by following
> https://doc.sagemath.org/html/en/installation/source.html
> but I get errors when it tries to compile the scipy-1.11.3 package. 
>
> I have attached config.log and scipy-1.11.3.log files for the full logs. 
> Here are the steps I took:
>
> 1. Created the directory ~/sage/
> 2. Downloaded source file and saved it in ~/sage/
> 3. tar xf sage-10.2.tar.gz 
> 4. cd sage-10.2/
> 5. export PATH=/usr/sbin/:/sbin/:/bin/:/usr/lib/wsl/lib/
> 6. export MAKE="make -j4 -l5.5" 
> 7. export V=0
> 8. ./configure --disable-editable 
> --prefix=/home/gkorpal/sage/sage-10.2/local
> 9. make
>
> Any help would be most welcome.
>
> Sincerely,
> Gaurish
>

-- 
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/904645c5-7d43-4d0e-8088-32129dbadfbdn%40googlegroups.com.

Re: [sage-devel] Re: Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Kwankyu Lee]

Hi, 

Appointing an editor (or editors) seems not a realistic solution, as it 
would be harder than resolving a disputed PR.

Forcing the code of conduct is not realistic either, as we have no means to 
force it.

I advocate for adopting a policy such as David Roe suggested for disputed 
PRs, as we all can agree to accept it, and then disputed PRs are resolved 
by  the common judgement of community members. The policy is nothing but a 
simple form of sage-devel votings that we are already used to.

On Thursday, January 11, 2024 at 6:59:22 AM UTC+9 Dima Pasechnik wrote:

>
>
> On 10 January 2024 20:29:28 GMT, Edgar Costa  wrote:
> >>
> >> I suspect it's due to the latter used to Sage the distro as a "missing
> >> macOS
> >> package manager".
> >> So they are happy adding more and more spkgs to Sage.
> >> And Linux users rightly see adding to Sage spkgs, which
> >> package software available on their systems in a regular way,
> >> as a bloat, which moreover needs constant attention -
> >> while sagelib suffers.
> >>
> >
> >macOS has several unofficial package managers.
> >In particular, homebrew makes it very easy for anyone to add a formula,
> >which is very similar to the way that spkg works.
> >
> indeed, and I even experimented with writing such formulae, e.g. for flint.
> https://github.com/sagemath/homebrew-science
>
> When it was discussed whether we wanted to use it, the main objection was 
> that it needs root (once, explicitly, to set up, then implicitly), thus 
> unsafe.
> Conda was mentioned as a better option. But Conda is much bigger.
>
> We do have a setup to use Homebrew.
>
>
>
>

-- 
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/e22c074f-e823-4107-8bbe-3b762bb52f85n%40googlegroups.com.

Re: [sage-devel] Re: Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Dima Pasechnik]

On 10 January 2024 20:29:28 GMT, Edgar Costa  wrote:
>>
>> I suspect it's due to the latter used to Sage the distro as a "missing
>> macOS
>> package manager".
>> So they are happy adding more and more spkgs to Sage.
>> And Linux users rightly see adding to Sage spkgs, which
>> package software available on their systems in a regular way,
>> as a bloat, which moreover needs constant attention -
>> while sagelib suffers.
>>
>
>macOS has several unofficial package managers.
>In particular, homebrew makes it very easy for anyone to add a formula,
>which is very similar to the way that spkg works.
>
indeed, and I even experimented with writing such formulae, e.g. for flint.
https://github.com/sagemath/homebrew-science

When it was discussed whether we wanted to use it, the main objection was that 
it needs root (once, explicitly, to set up, then implicitly), thus unsafe.
Conda was mentioned as a better option. But Conda is much bigger.

We do have a setup to use Homebrew.



-- 
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/513F1A86-1BA9-46EB-B93D-8C3BD81D6898%40gmail.com.

[sage-devel] Re: meta tickets

[Matthias Koeppe]

1. I think many of these uses have been made obsolete by the automatic 
pingbacks that appear when an Issue/PR is mentioned elsewhere. For example, 
in PR https://github.com/sagemath/sage/pull/36951, I included the text "- 
Part of https://github.com/sagemath/sage/issues/33577";, which created a 
"This was referenced" message over there.

2. Additional links can be added just by posting a reply in the Meta-Issue. 
When it becomes useful to incorporate it in the description, either the 
original creator of the Meta-Issue and also anyone in the Maintainer role 
can do so. 

3. The current assignments of roles in the GitHub project (above the level 
of the Triage team; in particular Maintainer and Admin roles) are the 
result of a not very clearly defined process. Now, 1 year after the 
migration of Sage development to GitHub, it would probably be a good timing 
to establish a clear process and review the current role assignments.


On Wednesday, January 10, 2024 at 8:08:35 AM UTC-8 Lorenz Panny wrote:

>
> Back in the days of trac, we sometimes had meta tickets that anyone
> could edit, for things such as wishlists or keeping track of larger
> projects. Some of these meta tickets were turned into GitHub issues,
> but now they are no longer editable by anyone except the original
> author (or so it seems). Is there any accepted way of dealing with
> this?
>

-- 
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/8f1d4371-6965-4bd3-8a0d-b8e4e7e3705bn%40googlegroups.com.

[sage-devel] Re: Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Volker Braun]

On Wednesday, January 10, 2024 at 2:37:59 PM UTC-5 Matthias Koeppe wrote:

[...] clarify the Code of Conduct and spell out its procedures and the 
range of sanctions


In case anyone missed this point, it is literally spelled out in William's 
original message:
 

For now, the main act of censure that the sage-abuse committee will be 
taking going forward will be to delete comments (on github and mailing 
lists) that violate the code of conduct.


 

-- 
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/bdf09d2b-db2a-4788-ba45-f7fcd739b7a1n%40googlegroups.com.

Re: [sage-devel] Re: Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Edgar Costa]

>
> I suspect it's due to the latter used to Sage the distro as a "missing
> macOS
> package manager".
> So they are happy adding more and more spkgs to Sage.
> And Linux users rightly see adding to Sage spkgs, which
> package software available on their systems in a regular way,
> as a bloat, which moreover needs constant attention -
> while sagelib suffers.
>

macOS has several unofficial package managers.
In particular, homebrew makes it very easy for anyone to add a formula,
which is very similar to the way that spkg works.

-- 
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/CA%2BiQ7x5Fm%2BWTmDb_%2Bz619M7LbmUrq6uNxgmYKGY9aotkx_r9Cw%40mail.gmail.com.

Re: [sage-devel] Re: Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Dima Pasechnik]

We have a problem of one developer, who decided, based on his, certainly, 
prolific contributions, that he can appoint himself a CTO of the project, and 
tell everyone who disagrees with him that it's a violation of CoC.


On 10 January 2024 19:37:58 GMT, Matthias Koeppe  
wrote:
>As I have explained to the current, semi-anonymous sage-abuse committee in 
>private communication:
>
>The framing of the dysfunction in the affected PRs 
>https://github.com/sagemath/sage/pulls?q=is%3Aopen+is%3Apr+label%3Adisputed as 
>mere "disputes" or "controversies" is misguided and harmful.
>
>We do not have a problem of project governance. 
>
>We have a problem of persistent, aggressive, escalating Code of Conduct 
>violations from a very small number of developers. (Key example with 
>pointers to other examples: https://github.com/sagemath/sage/pull/36726; 
>Trigger Warning: abusive language).
>
>And we have the problem of a lack of enforcement of the Code of Conduct.
>
>Easy to read overview on best practices: 
>https://opensource.guide/code-of-conduct/
>One key quote:
>- "A code of conduct that isn’t (or can’t be) enforced is worse than no 
>code of conduct at all: it sends the message that the values in the code of 
>conduct aren’t actually important or respected in your community."
>
>So I think we should start with electing a new sage-abuse committee that is 
>willing to publicly affirm and enforce the Code of Conduct. I would suggest 
>that nominations (including self-nominations) be sent to this list by Jan 
>24.
>
>The new committee should work with the community to clarify the Code of 
>Conduct and spell out its procedures and the range of sanctions that it 
>will conisder (see https://github.com/sagemath/sage/pull/36844).
>
>Matthias
>
>On Wednesday, January 10, 2024 at 6:50:10 AM UTC-8 William Stein wrote:
>
>> Dear Sage Developers,
>>
>> 1. There are over 20 pull requests labeled as "disputed" [1]. To
>> resolve these pull requests, we will be appointing an editor with no
>> direct involvement in the pull request to make a judgement call on
>> that particular pull request. We will then fully support the
>> decision of this editor. If you have the time to be the (possibly
>> anonymous) editor for a disputed pull request, please email us
>> (wst...@gmail.com, vbrau...@gmail.com) and we'll add your name to
>> our list.
>>
>> 2. There are numerous recent reports of violations of the code of
>> conduct to the sage-abuse mailing list. The code of conduct should
>> not be used as a tool in case you don't agree with somebody else. For
>> now, the main act of censure that the sage-abuse committee will be
>> taking going forward will be to delete comments (on github and mailing
>> lists) that violate the code of conduct.
>>
>> We do not have much time to devote to Sage development. However, we
>> both very much want things to move forward in a friendly and
>> encouraging way, and we would greatly appreciate it if the community
>> of Sage developers will support the above plan to move things forward
>> and ensure a positive experience for everyone participating in Sage
>> development.
>>
>> Best regards,
>>
>> Volker Braun and William Stein
>>
>> [1] 
>> https://github.com/sagemath/sage/pulls?q=is%3Aopen+is%3Apr+label%3Adisputed
>>
>> -- 
>> William (http://wstein.org)
>>
>
>-- 
>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/dc2fe40c-5ae7-4554-9e29-a71aa5841b92n%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/418E2F67-4F86-4059-BD8A-83390488681A%40gmail.com.

[sage-devel] Re: Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Matthias Koeppe]

As I have explained to the current, semi-anonymous sage-abuse committee in 
private communication:

The framing of the dysfunction in the affected PRs 
https://github.com/sagemath/sage/pulls?q=is%3Aopen+is%3Apr+label%3Adisputed as 
mere "disputes" or "controversies" is misguided and harmful.

We do not have a problem of project governance. 

We have a problem of persistent, aggressive, escalating Code of Conduct 
violations from a very small number of developers. (Key example with 
pointers to other examples: https://github.com/sagemath/sage/pull/36726; 
Trigger Warning: abusive language).

And we have the problem of a lack of enforcement of the Code of Conduct.

Easy to read overview on best practices: 
https://opensource.guide/code-of-conduct/
One key quote:
- "A code of conduct that isn’t (or can’t be) enforced is worse than no 
code of conduct at all: it sends the message that the values in the code of 
conduct aren’t actually important or respected in your community."

So I think we should start with electing a new sage-abuse committee that is 
willing to publicly affirm and enforce the Code of Conduct. I would suggest 
that nominations (including self-nominations) be sent to this list by Jan 
24.

The new committee should work with the community to clarify the Code of 
Conduct and spell out its procedures and the range of sanctions that it 
will conisder (see https://github.com/sagemath/sage/pull/36844).

Matthias

On Wednesday, January 10, 2024 at 6:50:10 AM UTC-8 William Stein wrote:

> Dear Sage Developers,
>
> 1. There are over 20 pull requests labeled as "disputed" [1]. To
> resolve these pull requests, we will be appointing an editor with no
> direct involvement in the pull request to make a judgement call on
> that particular pull request. We will then fully support the
> decision of this editor. If you have the time to be the (possibly
> anonymous) editor for a disputed pull request, please email us
> (wst...@gmail.com, vbrau...@gmail.com) and we'll add your name to
> our list.
>
> 2. There are numerous recent reports of violations of the code of
> conduct to the sage-abuse mailing list. The code of conduct should
> not be used as a tool in case you don't agree with somebody else. For
> now, the main act of censure that the sage-abuse committee will be
> taking going forward will be to delete comments (on github and mailing
> lists) that violate the code of conduct.
>
> We do not have much time to devote to Sage development. However, we
> both very much want things to move forward in a friendly and
> encouraging way, and we would greatly appreciate it if the community
> of Sage developers will support the above plan to move things forward
> and ensure a positive experience for everyone participating in Sage
> development.
>
> Best regards,
>
> Volker Braun and William Stein
>
> [1] 
> https://github.com/sagemath/sage/pulls?q=is%3Aopen+is%3Apr+label%3Adisputed
>
> -- 
> William (http://wstein.org)
>

-- 
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/dc2fe40c-5ae7-4554-9e29-a71aa5841b92n%40googlegroups.com.

Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Dima Pasechnik]

On Wednesday, January 10, 2024 at 3:21:54 PM UTC Michael Orlitzky wrote:

On Wed, 2024-01-10 at 06:49 -0800, William Stein wrote: 
> Dear Sage Developers, 
> 
> 1. There are over 20 pull requests labeled as "disputed" [1]. To 
> resolve these pull requests, we will be appointing an editor with no 
> direct involvement in the pull request to make a judgement call on 
> that particular pull request. We will then fully support the 
> decision of this editor. If you have the time to be the (possibly 
> anonymous) editor for a disputed pull request, please email us 
> (wst...@gmail.com, vbrau...@gmail.com) and we'll add your name to 
> our list. 
> 

Many of these are disputed for the same underlying reasons. Appointing 
a different editor for each PR is not likely to help. If you pick an 
editor from Camp A, he or she will always rule in favor of Camp A; pick 
an editor from Camp B... 


The camps are roughly split across the question whether
Sage the distro should be deemphasized, and the development
process should be centered around sagelib, or not.

As well, and it's not a coincidence, roughly the same partition
is on the basis of the developer platform used by the camp member.
It appears that the Linux users are primarily for deemphasizing 
Sage the distro, and macOS user are primarily against.

I suspect it's due to the latter used to Sage the distro as a "missing macOS
package manager". 
So they are happy adding more and more spkgs to Sage.
And Linux users rightly see adding to Sage spkgs, which
package software available on their systems in a regular way,
as a bloat, which moreover needs constant attention - 
while sagelib suffers.

I don't think that without solving this conflict the disputed PRs
dispute can be solved.

I may go on discussing how the Sage macOS problems may be
mitigated, but not here and now.

Dima


I foresee several problems resulting: 

1. We'll wind up with disputes about how the editor was chosen in 
place of disputed PRs. 

2. The editor is essentially ruling in favor of a development 
philosophy, and it would make little sense to rule against 
the opinion of the majority of sage developers (if there is 
such a thing). 

3. It often doesn't make sense to rule in favor of Camp A for 
one PR and Camp B for another. 

4. It enables editor shopping and PR ping pong. Rule against me 
the first time? I can try again in two weeks and hope for a 
different editor. 

Different journal editors can accept competing publications without 
much harm, but here that's not the case. 

-- 
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/c989ac2e-51fd-4806-bf1e-5202375497ebn%40googlegroups.com.

Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Volker Braun]

Appointing an editor is not supposed to be part of normal review. This is 
for the (hopefully rare) cases where we, the community, horribly failed in 
the code review process and for whatever reason no consensus can be found 
among the issue participants. The code review should have been a 
cooperative group decisions of the issue participants.

If anyone thinks they can game the system by being a general nuisance and 
starting review wars in every issue to force editor decisions, then I'd 
encourage them to rethink their approach.


-- 
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/dd1261c7-4bcc-40cb-9c45-ee77adfde077n%40googlegroups.com.

Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

['Martin R' via sage-devel]

Maybe it would make sense to appoint a group of editors, rather than a 
single editor, and this group decides per vote?  I'd feel much better if 
the responsibility is at least a little bit distributed between several 
people, and, most importantly, people who have been around for some time.

(Please note that I have no idea what these disputed PRs are really about.  
I looked at some of them, but was unable to see how they might affect me.)

Martin

On Wednesday 10 January 2024 at 16:21:54 UTC+1 Michael Orlitzky wrote:

> On Wed, 2024-01-10 at 06:49 -0800, William Stein wrote:
> > Dear Sage Developers,
> > 
> > 1. There are over 20 pull requests labeled as "disputed" [1]. To
> > resolve these pull requests, we will be appointing an editor with no
> > direct involvement in the pull request to make a judgement call on
> > that particular pull request. We will then fully support the
> > decision of this editor. If you have the time to be the (possibly
> > anonymous) editor for a disputed pull request, please email us
> > (wst...@gmail.com, vbrau...@gmail.com) and we'll add your name to
> > our list.
> > 
>
> Many of these are disputed for the same underlying reasons. Appointing
> a different editor for each PR is not likely to help. If you pick an
> editor from Camp A, he or she will always rule in favor of Camp A; pick
> an editor from Camp B...
>
> I foresee several problems resulting:
>
> 1. We'll wind up with disputes about how the editor was chosen in
> place of disputed PRs.
>
> 2. The editor is essentially ruling in favor of a development 
> philosophy, and it would make little sense to rule against
> the opinion of the majority of sage developers (if there is
> such a thing).
>
> 3. It often doesn't make sense to rule in favor of Camp A for
> one PR and Camp B for another.
>
> 4. It enables editor shopping and PR ping pong. Rule against me
> the first time? I can try again in two weeks and hope for a
> different editor.
>
> Different journal editors can accept competing publications without
> much harm, but here that's not the case.
>

-- 
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/93374416-398b-49fc-a5c8-2ad7982efdf2n%40googlegroups.com.

[sage-devel] meta tickets

['Lorenz Panny' via sage-devel]

Back in the days of trac, we sometimes had meta tickets that anyone
could edit, for things such as wishlists or keeping track of larger
projects. Some of these meta tickets were turned into GitHub issues,
but now they are no longer editable by anyone except the original
author (or so it seems). Is there any accepted way of dealing with
this?

-- 
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/20240110170829.0c127eb8%40l4.

Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Michael Orlitzky]

On Wed, 2024-01-10 at 06:49 -0800, William Stein wrote:
> Dear Sage Developers,
> 
> 1. There are over 20 pull requests labeled as "disputed" [1].  To
> resolve these pull requests, we will be appointing an editor with no
> direct involvement in the pull request to make a judgement call on
> that particular pull request.   We will then fully support the
> decision of this editor. If you have the time to be the (possibly
> anonymous) editor for a disputed pull request, please email us
> (wst...@gmail.com, vbraun.n...@gmail.com) and we'll  add your name to
> our list.
> 

Many of these are disputed for the same underlying reasons. Appointing
a different editor for each PR is not likely to help. If you pick an
editor from Camp A, he or she will always rule in favor of Camp A; pick
an editor from Camp B...

I foresee several problems resulting:

  1. We'll wind up with disputes about how the editor was chosen in
 place of disputed PRs.

  2. The editor is essentially ruling in favor of a development 
 philosophy, and it would make little sense to rule against
 the opinion of the majority of sage developers (if there is
 such a thing).

  3. It often doesn't make sense to rule in favor of Camp A for
 one PR and Camp B for another.

  4. It enables editor shopping and PR ping pong. Rule against me
 the first time? I can try again in two weeks and hope for a
 different editor.

Different journal editors can accept competing publications without
much harm, but here that's not the case.

-- 
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/8d3dbe043ffe7bc6f6e60d2994c67abaebf97796.camel%40orlitzky.com.

[sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[William Stein]

Dear Sage Developers,

1. There are over 20 pull requests labeled as "disputed" [1].  To
resolve these pull requests, we will be appointing an editor with no
direct involvement in the pull request to make a judgement call on
that particular pull request.   We will then fully support the
decision of this editor. If you have the time to be the (possibly
anonymous) editor for a disputed pull request, please email us
(wst...@gmail.com, vbraun.n...@gmail.com) and we'll  add your name to
our list.

2. There are numerous recent reports of violations of the code of
conduct to the sage-abuse mailing list.   The code of conduct should
not be used as a tool in case you don't agree with somebody else.  For
now, the main act of censure that the sage-abuse committee will be
taking going forward will be to delete comments (on github and mailing
lists) that violate the code of conduct.

We do not have much time to devote to Sage development.  However, we
both very much want things to move forward in a friendly and
encouraging way, and we would greatly appreciate it if the community
of Sage developers will support the above plan to move things forward
and ensure a positive experience for everyone participating in Sage
development.

Best regards,

Volker Braun and William Stein

[1] https://github.com/sagemath/sage/pulls?q=is%3Aopen+is%3Apr+label%3Adisputed

-- 
William (http://wstein.org)

-- 
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/CACLE5GBjCsVHFNYy7taSYFOZbCRFzorjuBgy%2BStaqOytnNbqqA%40mail.gmail.com.

[sage-devel] Re: Regarding deprecation of a property

[Nils Bruin]

On Wednesday 10 January 2024 at 03:03:09 UTC-8 Martin R wrote:

... What would be a good name?  Brainstorming: `coefficient_system`, 
`coefficients`, `coefficients_monomials`, 
`coefficient_matrix_monomial_vector`...


I think coefficients_monomials() is the most descriptive, as it tells you 
what you get back and in what order.

C, m = PS.coefficients_monomials()
assert PolynomialSequence(C*m) == PS

(incidentally, the assert also holds true with the return values of 
coefficient_matrix)

Also, thinking about whether C should be transposed: I think it's logical 
that the rows of C are the coefficients of members of the sequence (since 
matrices are closest to sequences of rows in sage), so C is already correct 
in that sense. Therefore, m should indeed be a "column" vector, but sage is 
ambivalent about whether vectors are rows or columns and therefore we can 
safely return it as a vector.

-- 
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/fb1b95b7-8ac1-42b0-b02d-bfdd10844077n%40googlegroups.com.

Re: [sage-devel] Re: Regarding deprecation of a property

['Lorenz Panny' via sage-devel]

How about .linearize()?

(I think this method should also optionally take a list
of monomials as an argument, since there are situations
in which users would like to force their own ordering.
Returning the same monomial vector again would then of
course be redundant, so in that case the method could
really return just the matrix.)


On Wed, 10 Jan 2024 12:03:09 +0100, 'Martin R' via sage-devel 
 wrote:
> I like this idea much better!  What would be a good name?  Brainstorming:
> `coefficient_system`, `coefficients`, `coefficients_monomials`,
> `coefficient_matrix_monomial_vector`...
> 
> On Wednesday 10 January 2024 at 09:06:36 UTC+1 Nils Bruin wrote:
> deprecation in a way that allows code to be adapted gradually would mean:
>  - introduce a new method with a different name that implements the desired
> behaviour
>  - deprecate old method
>  - after appropriate deprecation period remove old method
>  - possibly, at this point introduce the now-vacated name as a synonym for
> the method with the desired method. Quite frankly I think
> "coefficient_matrix" is the wrong name anyway: I'd expect such a method to
> return a matrix, but it returns a tuple (both in the old and the new
> version). So I think step 4 can be skipped in this case.
> 
> Note that often deprecation remains the state for very long: the motivation
> for actually removing functionality is pretty minimal.
> 
> 
> On Tuesday 9 January 2024 at 23:49:37 UTC-8 Ruchit Jagodara wrote:
> Currently, the PolynomialSequence.coefficient_matrix() function returns a
> matrix of monomials as the second element of a tuple. However, as discussed
> in issue
> [#37027](https://github.com/sagemath/sage/issues/37027),
> it has been suggested that returning a vector of monomials would be more
> logical. I am uncertain about the correct approach to deprecate the current
> behavior. I have submitted a pull request with the proposed changes at PR
> [#37035](https://github.com/sagemath/sage/pull/37035),
> but I would appreciate guidance on whether this is the appropriate way to
> deprecate the property.
> 
> --
> 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/00253792-8260-43aa-b449-4a04de540ad8n%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/20240110143055.6052b592%40l4.

[sage-devel] Re: Regarding deprecation of a property

['Martin R' via sage-devel]

I like this idea much better!  What would be a good name?  Brainstorming: 
`coefficient_system`, `coefficients`, `coefficients_monomials`, 
`coefficient_matrix_monomial_vector`...

On Wednesday 10 January 2024 at 09:06:36 UTC+1 Nils Bruin wrote:

> deprecation in a way that allows code to be adapted gradually would mean:
>  - introduce a new method with a different name that implements the 
> desired behaviour
>  - deprecate old method
>  - after appropriate deprecation period remove old method
>  - possibly, at this point introduce the now-vacated name as a synonym for 
> the method with the desired method.
> Quite frankly I think "coefficient_matrix" is the wrong name anyway: I'd 
> expect such a method to return a matrix, but it returns a tuple (both in 
> the old and the new version). So I think step 4 can be skipped in this case.
>
> Note that often deprecation remains the state for very long: the 
> motivation for actually removing functionality is pretty minimal.
>
>
> On Tuesday 9 January 2024 at 23:49:37 UTC-8 Ruchit Jagodara wrote:
>
>> Currently, the PolynomialSequence.coefficient_matrix() function returns a 
>> matrix of monomials as the second element of a tuple. However, as discussed 
>> in issue [#37027](https://github.com/sagemath/sage/issues/37027), it has 
>> been suggested that returning a vector of monomials would be more logical. 
>> I am uncertain about the correct approach to deprecate the current 
>> behavior. I have submitted a pull request with the proposed changes at PR 
>> [#37035](https://github.com/sagemath/sage/pull/37035), but I would 
>> appreciate guidance on whether this is the appropriate way to deprecate the 
>> property.
>>
>

-- 
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/00253792-8260-43aa-b449-4a04de540ad8n%40googlegroups.com.

[sage-devel] Re: Regarding deprecation of a property

[Nils Bruin]

deprecation in a way that allows code to be adapted gradually would mean:
 - introduce a new method with a different name that implements the desired 
behaviour
 - deprecate old method
 - after appropriate deprecation period remove old method
 - possibly, at this point introduce the now-vacated name as a synonym for 
the method with the desired method.
Quite frankly I think "coefficient_matrix" is the wrong name anyway: I'd 
expect such a method to return a matrix, but it returns a tuple (both in 
the old and the new version). So I think step 4 can be skipped in this case.

Note that often deprecation remains the state for very long: the motivation 
for actually removing functionality is pretty minimal.


On Tuesday 9 January 2024 at 23:49:37 UTC-8 Ruchit Jagodara wrote:

> Currently, the PolynomialSequence.coefficient_matrix() function returns a 
> matrix of monomials as the second element of a tuple. However, as discussed 
> in issue [#37027](https://github.com/sagemath/sage/issues/37027), it has 
> been suggested that returning a vector of monomials would be more logical. 
> I am uncertain about the correct approach to deprecate the current 
> behavior. I have submitted a pull request with the proposed changes at PR 
> [#37035](https://github.com/sagemath/sage/pull/37035), but I would 
> appreciate guidance on whether this is the appropriate way to deprecate the 
> property.
>

-- 
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/09fd753c-606f-4d84-8557-8a2798daf5ccn%40googlegroups.com.