[sage-devel] Re: Using Sage on Windows

[seb....@gmail.com]

> *Let me know how it works for you*

See my report on https://github.com/sagemath/sage-binder-env/issues/20.
Kwankyu Lee schrieb am Montag, 21. Oktober 2024 um 09:56:39 UTC+2:

> On Monday, October 21, 2024 at 3:23:16 PM UTC+9 seb@gmail.com wrote:
>
> > *The third version is ready:*
>
> I tested it on Saturday, but with the same result as before.
>
>
> Right. I missed your point. The installer's check for WSL installation was 
> deficient. Now I made an improvement. Let me know how it works for you.  
>
>  
>

-- 
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/ad86be51-6d2e-4110-b168-2d2d6e499c51n%40googlegroups.com.

[sage-devel] Re: Using Sage on Windows

[seb....@gmail.com]

> *The third version is ready:*

I tested it on Saturday, but with the same result as before. I will open an 
issue in the sage-binder-env repository 
 later on to document my tests 
there.
Kwankyu Lee schrieb am Samstag, 19. Oktober 2024 um 18:28:36 UTC+2:

> The third version is ready: 
> https://github.com/sagemath/sage-binder-env/releases/tag/v10.4

-- 
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/36943f45-68e5-4242-9dc9-4a623bf0b658n%40googlegroups.com.

Re: [sage-devel] A new logo?

[seb....@gmail.com]

> *I designed the suggested logo to reflect the identity.*

My interpretation of the existing logo is a visualization of the Euler 
characteristic formula (pointing out edges and vertices). It therefore 
represents an example of a connection between Algebra and Geometry, with 
both representing half of the letters of the name Sage. This seems to be 
lost in your proposal. It makes sense to improve the quality of the image, 
but the message should remain.

Kwankyu Lee schrieb am Montag, 21. Oktober 2024 um 06:08:55 UTC+2:

> On Monday, October 21, 2024 at 8:47:02 AM UTC+9 Michael Orlitzky wrote:
>
> * The icosahedron strikes me as an instance of "hey give me the name 
> of a cool math shape" that has nothing to do with sage itself
>
>
> The icosahedron in the current logo looks broken to me. I wonder what was 
> the intention. 
>
> * The font can be ugly, and if you don't know that it says "sage" 
> already, it's hard to read
>
>
> That is the main reason that I dislike it. 
>  
>
> However, we've had the same logo (and font) for a long time, and for 
> better or worse, they're our identity. 
>
>
> Depending on how much details of the current logo you think are "our 
> identity", I designed the suggested logo to reflect the identity..
>

-- 
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/d893cef6-549b-471b-bc02-52144625323en%40googlegroups.com.

Re: [sage-devel] A new logo?

[seb....@gmail.com]

>  *nothing wrong with looking at alternatives, of course, but personally I 
do like the current logo (both absolutely speaking and in comparison to the 
designs suggested here thus far).*

+1

In addition I think there should be more reasons for changing the logo than 
just: "*I don't like it anymore!*". It has been our identification symbol 
for many years, not only on our website but also in many other places 
(Wikipedia, Docker Hub, ...) and people are used to it.
lor...@yx7.cc schrieb am Sonntag, 20. Oktober 2024 um 19:48:00 UTC+2:

> Hi Kwankyu,
>
> nothing wrong with looking at alternatives, of course, but personally
> I do like the current logo (both absolutely speaking and in comparison
> to the designs suggested here thus far).
>
> Best,
> Lorenz
>
>
> On Sun, 20 Oct 2024 02:21:32 -0700 (PDT), Kwankyu Lee  
> wrote:
> > Hi 
> > 
> > As some of you who tried 
> > 
> > https://github.com/sagemath/sage-binder-env/releases/tag/v10.4
> > 
> > may have noticed, I did a bit creative work on icons. Thus I came up 
> with 
> > an idea of a new logo for Sage. Check out the attached png file.
> > 
> > Personally I dislike the current Sage logo, both the icon and the sci-fi 
> > font.
> > 
> > As you would notice, the icon, the blue icosahedron, is just the output 
> of 
> > a simple plot command of Sage.
> > 
> > What do you think?
> > 
> > 
> > -- 
> > 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/f0551303-eac4-438f-8f2d-a9782a83ea06n%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/2dae3f8c-8bfd-46b3-85b8-5b7a37a3cd35n%40googlegroups.com.

[sage-devel] Re: Using Sage on Windows

[seb....@gmail.com]

Have you looked for overlap with Julian's work?

I noticed a regression in your new version. It started with "Downloading 
and extracting SageMath..." before installing WSL.

Kwankyu Lee schrieb am Freitag, 18. Oktober 2024 um 16:58:36 UTC+2:

> On Friday, October 18, 2024 at 4:45:39 PM UTC+9 seb@gmail.com wrote:
>
> > *I auto-created a powershell script  to make this even easier ...*
>
> Interesting! How did you auto-create that? With a translation tool?
>
>
> Just by github action :-) 
>
> > *Needs test.*
>
> I tried it in a Hyper-V guest running a freshly installed Windows 11 Home.
>
>
> Thanks for trying. Meanwhile, I improved the installer. Now it is in 
> https://github.com/sagemath/sage-binder-env/releases/tag/v10.4
>

-- 
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/ff0438f7-e0db-44cf-b747-6eaad04c40fan%40googlegroups.com.

[sage-devel] Re: Using Sage on Windows

[seb....@gmail.com]

> 
*I auto-created a powershell script  to make this even easier ...*
Interesting! How did you auto-create that? With a translation tool?

> *Needs test.*

I tried it in a Hyper-V guest running a freshly installed Windows 11 Home. 
I couldn't run the script by copying the code into a Powershell terminal. 
But after saving it in a file test.ps1, it ran through (after a reboot due 
to WSL activation), but Sage doesn't appear on Linux distributions. This is 
what I got:
[image: TestWSLimport.png]


Kwankyu Lee schrieb am Donnerstag, 17. Oktober 2024 um 08:00:18 UTC+2:

> Another alternative would be to import the docker image as a WSL 
> distribution. From a user perspective, this would be simply setting up WSL, 
> downloading the docker image as a tar file and then run wsl --import 
> SageMath . The tar file could be automatically 
> generated from the docker image upon releasing a new version of sage (in 
> github ci). See 
> https://learn.microsoft.com/en-us/windows/wsl/use-custom-distro. But I 
> don't have experience with this mode of installation, so I don't know if 
> there are hidden shortcomings.
>
>
> I am experimenting this mode of installation. Yes, this may be the easiest 
> way for a windows user to get a working sage install.
>
> I auto-created a powershell script  to make this even easier:
>
>
> https://github.com/sagemath/sage-binder-env/blob/master/download_and_import_sagemath_to_wsl.ps1
>
> Needs test. The tar file is currently a github artifact, and is not freely 
> downloadable. It seems that sagemath organization membership is necessary 
> to access it. 
>
> The wsl image tar file is of size about 6GB.  It would be nice if we have 
> a public file server to accommodate the tar file.
>
>
>
>

-- 
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/8e0edcbe-28da-4e05-9bb2-d2e80c2847ean%40googlegroups.com.

[sage-devel] Re: Using Sage on Windows

[seb....@gmail.com]

 > *Do you want to add it to the docs?*

Yes! But first there should be something like a review based on the testing 
experiences of other users.

>* Another alternative would be to import the docker image as a WSL 
distribution*

Thanks for the hint. My impression is that this is essentially the approach 
Julian took. The main difference with my approach is that the decision of 
which version of Sage to install has to be made at installation time. If 
you use Docker, this is more of a runtime decision. With my approach, the 
user selects the Sage version from a list (see section 2.3 
 in 
the documentation). Installing Sage is then done simply by `docker pull`. 
This makes it easier to upgrade Sage, keep a previous version for a while, 
and use multiple Sage versions in parallel.


tobia...@gmx.de schrieb am Donnerstag, 17. Oktober 2024 um 06:35:59 UTC+2:

I'm very happy to see improvements to the Windows installation. I don't 
have the time right now to try your powershell script, but it looks like a 
nice walk-through for not-so-technical users. Do you want to add it to the 
docs?

Another alternative would be to import the docker image as a WSL 
distribution. From a user perspective, this would be simply setting up WSL, 
downloading the docker image as a tar file and then run wsl --import 
SageMath . The tar file could be automatically 
generated from the docker image upon releasing a new version of sage (in 
github ci). See 
https://learn.microsoft.com/en-us/windows/wsl/use-custom-distro. But I 
don't have experience with this mode of installation, so I don't know if 
there are hidden shortcomings.


On Wednesday, October 16, 2024 at 7:45:14 PM UTC+8 Eric Gourgoulhon wrote:

Thank you very much Julian and Sebastian for these initiatives!
On ask.sagemath, we see too many messages from Windows users not managing 
to install Sage. A recent example is
https://ask.sagemath.org/question/79640/error-during-configuration-with-wsl/
We also see messages from users stuck to Sage 9.3, which is the latest 
Cygwin version...

Eric. 

-- 
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/ed9bbd74-8c53-4b42-a257-fb85ad37213en%40googlegroups.com.

[sage-devel] Using Sage on Windows

[seb....@gmail.com]

Dear Sage developers,

As you all know, there are some obstacles to using Sage on Windows. For a 
few years, this was much easier due to binaries built with Cygwin. Since 
this has been discontinued, we direct Windows users to the Linux 
installation procedures via WSL. Alternatively, we direct them to use our 
Docker images on Docker Hub.

For people with development experience, these installation instructions are 
fine. But if we want to appeal to people without such experience, we should 
offer more help.

Recently, Julian Rüth developed an installation script that simplifies the 
installation process via WSL (see this comment 
 on 
#33765  and these release 
notes  of the 
Flatsurf project).

For the approach with our images on Docker Hub, I started implementing a 
Powershell script that guides the user through the process. You can find it 
in this repository  along 
with documentation in the `README.md` file. Please consider it a draft 
illustrating a suggestion and feel free to help make it into something 
useful.

Note that you can test the main part of the tool even if you don't have 
access to a system running Windows. At least if you are using Linux (I 
don't know about Mac), you can follow section 4 
 of the documentation.

Sebastian

-- 
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/b766e523-5442-40d7-a63c-db0ae8d1f6c4n%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels continues on Tuesday July 11th

[seb....@gmail.com]

This would replace something annoying for senior developers by something 
annoying for new contributors. I'm not sure if this is a good idea.

Did you have to manually resolve merge conflicts in your example? If not, 
just don't push it back to the repository in such a situation in the 
future. If so, I agree with Tobias that *needs review* is a correct status.

Kwankyu Lee schrieb am Montag, 5. August 2024 um 12:50:53 UTC+2:

>  But more importantly, if we disable this action, it would be a regression 
> for developers who cannot set labels themselves.
>
>
> Isn't it enough to add "needs review" label only when draft PR is 
> converted to a non-draft PR? Those developers may control the draft status. 
>

-- 
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/0362e752-9290-44c7-bfdc-1bc652d5b719n%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels continues on Tuesday July 11th

[seb....@gmail.com]

I see! On the other hand, you do benefit from this bot action after pushing 
changes to a non-draft PR (which probably happens much more often). But 
more importantly, if we disable this action, it would be a regression for 
developers who cannot set labels themselves.

Kwankyu Lee schrieb am Montag, 5. August 2024 um 03:49:22 UTC+2:

> On Sunday, August 4, 2024 at 9:48:55 PM UTC+9 seb....@gmail.com wrote:
>
> We've already discussed this here: 
> https://github.com/sagemath/sage/pull/36213#issuecomment-1711595430 and 
> Tobias made a good argument for leaving it as is in 
> https://github.com/sagemath/sage/pull/36213#issuecomment-1711640422.
>
>
> Once positively reviewed, we usually leave it to the author to keep the PR 
> branch in good state to be merged with the develop branch. This is like 
> "checking galley proof" stage of publishing a research paper.
>  
>
> What was the reason for rebasing a positively reviewed PR?
>
>
> To see if the PR branch still work with the new develop branch (by running 
> checks all again).
>  
>

-- 
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/566b1fdc-5064-4e5f-8950-302b1016c3edn%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels continues on Tuesday July 11th

[seb....@gmail.com]

We've already discussed this here: 
https://github.com/sagemath/sage/pull/36213#issuecomment-1711595430 and 
Tobias made a good argument for leaving it as is in 
https://github.com/sagemath/sage/pull/36213#issuecomment-1711640422.

What was the reason for rebasing a positively reviewed PR?

Kwankyu Lee schrieb am Sonntag, 4. August 2024 um 13:10:07 UTC+2:

> Hi
>
> It seems that synchronization script adds "needs review" label whenever a 
> new commit is uploaded to (non-draft) PR.
>
> If a merge (with develop branch) commit is uploaded to a PR that has 
> already got "positive review" label, then the "positive review" label is 
> replaced with "needs review" label. This is annoying.
>
> How about adding "needs review" label only when draft PR is converted to a 
> non-draft PR?
>

-- 
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/f2ae6083-56d3-413c-9035-73d17a5da144n%40googlegroups.com.

[sage-devel] Re: New labels v: mimimal, v: small ... on pull requests

[seb....@gmail.com]

> *One such functionality is to add component labels (aka "c:" labels) 
automatically by analyzing what part of sage codebase the PR branch 
touches.*

This is #37373 . Temporarily 
this has been part of #37262 . 
But finally it has been kept off. 

Kwankyu Lee schrieb am Samstag, 15. Juni 2024 um 09:18:32 UTC+2:

> I agree with what Vincent said in the other thread. Thus for decision 
> (A1), we just turn the script off so that  we could revive it in future for 
> some other useful functionality.
>
> One such functionality is to add component labels (aka "c:" labels) 
> automatically by analyzing what part of sage codebase the PR branch touches.
>

-- 
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/3099c71c-5cd2-43ca-8c3d-800597d2fd9an%40googlegroups.com.

Re: [sage-devel] Re: Vote: Removing Automatic PR Size Labels

[seb....@gmail.com]

> *The feature might have been wrongly guided*

I'm sorry, that was my mistake (see my recent comment 
in 
#37262 ). This caused that 
there is a difference between B and B7.

>  *Nevertheless, it would be very unwelcoming to just revert it.*

This is the motivation behind Option A3.


Vincent Delecroix schrieb am Samstag, 15. Juni 2024 um 08:52:00 UTC+2:

> On the material side I vote (A1).
>
> On the human side I vote (B). Matthias raised a delicate point: this
> feature was introduced by a newcomer to sage development. The feature
> might have been wrongly guided or badly thought. Nevertheless, it
> would be very unwelcoming to just revert it.
>
> Ideally, there would be a "make the feature even nicer" solution
> rather than "get rid of that s***". Though, this requires a concrete
> proposal more than a vote, and I have nothing magical to share at this
> stage.
>
> Best
> Vincent
>
> On Fri, 14 Jun 2024 at 13:56, Kwankyu Lee  wrote:
> >
> > +1 to (A1)
> >
> > --
> > 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/cd9f975b-3605-4e98-a165-2a2e1d4ab2b9n%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/cb54d564-ed2e-4256-b10c-b3309832ec57n%40googlegroups.com.

Re: [sage-devel] Re: Vote: Removing Automatic PR Size Labels

[seb....@gmail.com]

Here I forward this post from Dima, which didn't find the right channel:










*Fri, Jun 14, 12:25 PM (3 days ago)Please record my vote for A3.I also 
wonder whether this setup has a side feature which would allowus to collect 
stats on the sizes of contributions.CheersDima*

Gareth Ma schrieb am Samstag, 15. Juni 2024 um 23:35:14 UTC+2:

> I vote for (A1) and no other options.
>
> In fact, I don't think size related labels should be a thing at all, so the
> second half of (A1), i.e. "the[y] must be added manually (like most other
> labels)", should preferably be removed as well. (The wording suggests they 
> will
> be kept and added manually.)
>
> On 6/15/24 7:49 AM, Vincent Delecroix wrote:
> > On the material side I vote (A1).
> > 
> > On the human side I vote (B). Matthias raised a delicate point: this
> > feature was introduced by a newcomer to sage development. The feature
> > might have been wrongly guided or badly thought. Nevertheless, it
> > would be very unwelcoming to just revert it.
> > 
> > Ideally, there would be a "make the feature even nicer" solution
> > rather than "get rid of that s***". Though, this requires a concrete
> > proposal more than a vote, and I have nothing magical to share at this
> > stage.
> > 
> > Best
> > Vincent
> > 
> > On Fri, 14 Jun 2024 at 13:56, Kwankyu Lee  wrote:
> >>
> >> +1 to (A1)
> >>
> >> --
> >> 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/cd9f975b-3605-4e98-a165-2a2e1d4ab2b9n%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/7104c4c7-f403-4ebd-94a7-5dc4f1c31188n%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels continues on Tuesday July 11th

[seb....@gmail.com]

We will continue with this next Tuesday (June 18th) with step four 
<https://github.com/sagemath/sage/issues/35927#issuecomment-2154204573>. 
After that the s: needs review label will be set automatically if you mark 
a draft as *ready for review* or push a new commit to a non draft PR.

seb@gmail.com schrieb am Montag, 10. Juni 2024 um 12:08:51 UTC+2:

> Currently ther are about 90 open PR's that are not drafts but don't have 
> any state label set (see this list 
> <https://github.com/sagemath/sage/pulls?page=2&q=is%3Aopen+is%3Apr+-label%3A%22s%3A+positive+review%22+-label%3A%22s%3A+needs+work%22+-label%3A%22s%3A+needs+info%22+-label%3A%22s%3A+needs+review%22+draft%3Afalse>).
>  
> Obviously not all of them are authored by developers who cannot set these 
> labels because they are not members of Triage. If you are a member of 
> Triage and one of your PRs is among them, you should pay attention to what 
> will change tomorrow:
>
> 1. If you simply forgot to set the s: needs review label, then the bot 
> will do it for you in the future.
> 2. If you intentionally didn't set s: needs review for your PR (for 
> example, because you want to check CI results first), then you should open 
> your PR as a *draft* in the future (see item 6 here 
> <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request#creating-the-pull-request>)
>  
> and change its status to r*eady for review* later on (see this page 
> <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request>).
>  
> Otherwise, the PR will have the s: needs review label from the start.
>
> seb@gmail.com schrieb am Freitag, 7. Juni 2024 um 23:54:07 UTC+2:
>
>> *Sorry, typo in the headline: July -> June!*
>>
>> seb@gmail.com schrieb am Freitag, 7. Juni 2024 um 23:49:54 UTC+2:
>>
>>> Dear Sage developers,
>>>
>>> We will now continue with a process that started last July 
>>> <https://groups.google.com/g/sage-devel/c/ElzW6XR4YAM/m/q9a0cEvgAQAJ>. 
>>> Unfortunately, this was blocked for many months while we waited for GitHub 
>>> to fix a bug in their web-interface. Although this bug is still not fixed 
>>> (see this comment on #35927 
>>> <https://github.com/sagemath/sage/issues/35927#issuecomment-2152993322>), 
>>> parts of label sync that are less critical to this bug should continue.
>>>
>>> As before, the bot will be enabled in several steps. These are tracked 
>>> in issue #35927 <https://github.com/sagemath/sage/issues/35927>. We are 
>>> moving on to step 3 
>>> <https://github.com/sagemath/sage/issues/35927#issuecomment-2154192483> 
>>> and 4 
>>> <https://github.com/sagemath/sage/issues/35927#issuecomment-2154204573>, 
>>> the first of which will be enabled next Tuesday. These steps will allow 
>>> developers who are not members of the Triage team to have the s: needs 
>>> review label on their PRs.
>>>
>>> Please post comments, suggestions and bug reports on #35927 
>>> <https://github.com/sagemath/sage/issues/35927>.
>>>
>>> Sebastian
>>>
>>

-- 
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/f54c9559-fc60-405f-9080-44c4b2747712n%40googlegroups.com.

[sage-devel] Re: Vote: Removing Automatic PR Size Labels

[seb....@gmail.com]

I vote for A3. If finally there are more votes for A1 than for B then you 
may count it for A2, as well.

julian...@fsfe.org schrieb am Donnerstag, 13. Juni 2024 um 23:20:39 UTC+2:

> I vote for (A1) and no other option.
>
> (I don't see enough added value of these labels and I think that any *list 
> approach is going to be a too obscure feature to warrant the extra effort 
> of maintaining it.)
>
> On Thursday, June 13, 2024 at 6:27:46 AM UTC+3 tcsc...@gmail.com wrote:
>
>> PR labels are being automatically added to roughly indicate their size. 
>> There are three options besides keeping the current behavior:
>>
>> (A1) Remove the automatic adding of labels; the must be added manually 
>> (like most other labels).
>> (A2) Have a "whitelist" of contributors who want to have this 
>> automatically added to their PRs.
>> (A3) Have a "blacklist" of contributors who do not want to have this 
>> automatically added to their PRs.
>> (B) Keep the current way of automatically adding it for all PRs.
>>
>> This will be assuming that if you vote for (Ai), your vote will 
>> automatically count for all (Aj) >= (Ai) unless you state otherwise. For 
>> example, if there are 3 votes for (A1), 2 votes for (A3) and 4 votes for 
>> (B), we will go with (A3) as the total is 5 votes.
>>
>> The vote will close on *Friday, June 21st*.
>>
>> For the discussion, see: 
>> https://groups.google.com/g/sage-devel/c/w4IeYgXgVUc/m/nV-ZT9BpAgAJ
>>
>> My vote: (A1)
>>
>> Best,
>> Travis
>>
>

-- 
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/78b9d183-2e04-4aa0-a525-bbcd7aa177abn%40googlegroups.com.

[sage-devel] Re: New labels v: mimimal, v: small ... on pull requests

[seb....@gmail.com]

I think that regardless of questions about governance models, we should 
take objections from community members seriously if they find something 
annoying. So why not offer them the possibility to set preferences for 
extensions to tools we have implemented ourselves? This has no impact on 
the goals of the project.

Kwankyu Lee schrieb am Mittwoch, 12. Juni 2024 um 04:05:16 UTC+2:

>
> You may want to take a second look. This article does not prescribe one 
> governance model. It describes several governance models. After reading it, 
> a more informed discussion will be possible among those who care about 
> questions of governance.
>
>
> Indeed, the article offers some useful terms. Our governance model is a 
> mixture of "do-ocracy", "council or board", "electoral" (it was 
> "founder-leader" at the beginning). 
>

-- 
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/5962f38b-5f90-425e-9986-968eb3919c3an%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels continues on Tuesday July 11th

[seb....@gmail.com]

Currently ther are about 90 open PR's that are not drafts but don't have 
any state label set (see this list 
<https://github.com/sagemath/sage/pulls?page=2&q=is%3Aopen+is%3Apr+-label%3A%22s%3A+positive+review%22+-label%3A%22s%3A+needs+work%22+-label%3A%22s%3A+needs+info%22+-label%3A%22s%3A+needs+review%22+draft%3Afalse>).
 
Obviously not all of them are authored by developers who cannot set these 
labels because they are not members of Triage. If you are a member of 
Triage and one of your PRs is among them, you should pay attention to what 
will change tomorrow:

1. If you simply forgot to set the s: needs review label, then the bot will 
do it for you in the future.
2. If you intentionally didn't set s: needs review for your PR (for 
example, because you want to check CI results first), then you should open 
your PR as a *draft* in the future (see item 6 here 
<https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request#creating-the-pull-request>)
 
and change its status to r*eady for review* later on (see this page 
<https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request>).
 
Otherwise, the PR will have the s: needs review label from the start.

seb@gmail.com schrieb am Freitag, 7. Juni 2024 um 23:54:07 UTC+2:

> *Sorry, typo in the headline: July -> June!*
>
> seb@gmail.com schrieb am Freitag, 7. Juni 2024 um 23:49:54 UTC+2:
>
>> Dear Sage developers,
>>
>> We will now continue with a process that started last July 
>> <https://groups.google.com/g/sage-devel/c/ElzW6XR4YAM/m/q9a0cEvgAQAJ>. 
>> Unfortunately, this was blocked for many months while we waited for GitHub 
>> to fix a bug in their web-interface. Although this bug is still not fixed 
>> (see this comment on #35927 
>> <https://github.com/sagemath/sage/issues/35927#issuecomment-2152993322>), 
>> parts of label sync that are less critical to this bug should continue.
>>
>> As before, the bot will be enabled in several steps. These are tracked in 
>> issue #35927 <https://github.com/sagemath/sage/issues/35927>. We are 
>> moving on to step 3 
>> <https://github.com/sagemath/sage/issues/35927#issuecomment-2154192483> 
>> and 4 
>> <https://github.com/sagemath/sage/issues/35927#issuecomment-2154204573>, 
>> the first of which will be enabled next Tuesday. These steps will allow 
>> developers who are not members of the Triage team to have the s: needs 
>> review label on their PRs.
>>
>> Please post comments, suggestions and bug reports on #35927 
>> <https://github.com/sagemath/sage/issues/35927>.
>>
>> Sebastian
>>
>

-- 
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/3835bcb7-6e96-44ac-b69c-9b232fa5b3a6n%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels continues on Tuesday July 11th

[seb....@gmail.com]

*Sorry, typo in the headline: July -> June!*

seb....@gmail.com schrieb am Freitag, 7. Juni 2024 um 23:49:54 UTC+2:

> Dear Sage developers,
>
> We will now continue with a process that started last July 
> <https://groups.google.com/g/sage-devel/c/ElzW6XR4YAM/m/q9a0cEvgAQAJ>. 
> Unfortunately, this was blocked for many months while we waited for GitHub 
> to fix a bug in their web-interface. Although this bug is still not fixed 
> (see this comment on #35927 
> <https://github.com/sagemath/sage/issues/35927#issuecomment-2152993322>), 
> parts of label sync that are less critical to this bug should continue.
>
> As before, the bot will be enabled in several steps. These are tracked in 
> issue #35927 <https://github.com/sagemath/sage/issues/35927>. We are 
> moving on to step 3 
> <https://github.com/sagemath/sage/issues/35927#issuecomment-2154192483> 
> and 4 
> <https://github.com/sagemath/sage/issues/35927#issuecomment-2154204573>, 
> the first of which will be enabled next Tuesday. These steps will allow 
> developers who are not members of the Triage team to have the s: needs 
> review label on their PRs.
>
> Please post comments, suggestions and bug reports on #35927 
> <https://github.com/sagemath/sage/issues/35927>.
>
> Sebastian
>

-- 
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/e463022b-42b5-4cfa-b39b-ee60b74e7115n%40googlegroups.com.

[sage-devel] Synchronization of GitHub state and priority labels continues on Tuesday July 11th

[seb....@gmail.com]

Dear Sage developers,

We will now continue with a process that started last July 
. 
Unfortunately, this was blocked for many months while we waited for GitHub 
to fix a bug in their web-interface. Although this bug is still not fixed 
(see this comment on #35927 
), 
parts of label sync that are less critical to this bug should continue.

As before, the bot will be enabled in several steps. These are tracked in 
issue #35927 . We are moving 
on to step 3 
 and 
4 , 
the first of which will be enabled next Tuesday. These steps will allow 
developers who are not members of the Triage team to have the s: needs 
review label on their PRs.

Please post comments, suggestions and bug reports on #35927 
.

Sebastian

-- 
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/525e0088-1a08-4941-80d7-47755460af73n%40googlegroups.com.

Re: [sage-devel] Re: New labels v: mimimal, v: small ... on pull requests

[seb....@gmail.com]

*> How about having a voting for this issue? *

Another possibility would be to have a blacklist (but I don't know where) 
that developers can sign up to if they want to be excluded from automations 
that apply to PRs. In this thread's example, a developer would exclude PRs 
that he himself authors or reviews from having the `v: ...` labels 
automatically set.

Kwankyu Lee schrieb am Dienstag, 28. Mai 2024 um 12:30:46 UTC+2:

I *very* strongly believe we should disable this automatically being added 
to PRs.


How about having a voting for this issue?
 

-- 
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/de71-a24f-4aba-b879-19de54e01e81n%40googlegroups.com.

[sage-devel] Re: New labels v: mimimal, v: small ... on pull requests

[seb....@gmail.com]

 *> (Note that only members of the Triage team can set the "needs review" 
label.)*

See this comment in #35927 
<https://github.com/sagemath/sage/issues/35927#issuecomment-2152993322> for 
a suggestion to solve this.


Matthias Koeppe schrieb am Dienstag, 28. Mai 2024 um 21:35:26 UTC+2:

> I'll expand a little bit, in the hope to stimulate a constructive 
> discussion. (A previous related thread: 
> https://groups.google.com/g/sage-devel/c/sulCa-6EZRA/m/86jFAw9NAAAJ)
>
> There is a very serious, project-level concern: Is our project welcoming 
> to new contributors? 
> We tell contributors to get started by preparing small simple PRs; but are 
> these PRs getting reviewed and merged?
>
> We currently have 177 open, non-draft, non-"positive review", non-"needs 
> work", non-"needs info" pull requests.
>
> https://github.com/sagemath/sage/pulls?q=is%3Aopen+is%3Apr+-label%3A%22s%3A+positive+review%22+-label%3A%22s%3A+needs+work%22+-label%3A%22s%3A+needs+info%22+draft%3Afalse
> (Note that only members of the Triage team can set the "needs review" 
> label.)
>
> What can we do to make sure that PRs get reviews?
> I frequently set component labels ("c: ...") on other people's unlabeled 
> Issues and PRs. Does this help at all?
> What labels would help people discover PRs that they would be able to 
> review?
>
> Matthias
>
> On Friday, May 10, 2024 at 7:02:19 AM UTC-7 Matthias Koeppe wrote:
>
> FWIW, I suggested to implement this feature in 
> https://github.com/sagemath/sage/issues/37254; I'm thankful to Aman Moon 
> for implementing this feature and Sebastian Oehms for his help with it. 
>
> Obviously a metric such as the number of lines of changes is only a 
> one-dimensional way to express the complexity of a PR. 
> When I suggested the feature, I explained the possible positive effects:
> - A size label "tiny" could encourage quick reviews of trivial changes.
> - A size label "huge" could help flag problematic PRs.
> Personally I think that the size labels for "medium-sized" PRs do not add 
> much and could be removed.
>
> But I'll note that "developer experience" improvements like this one are 
> really best developed exactly as it was done here: By deploying them early, 
> the developer community can gain concrete experience with them -- and then 
> suggest and implement refinements based on the experience. Harsh dismissals 
> of the whole features, on the other hand, are not very helpful.
>
> Matthias
>
> On Thursday, May 9, 2024 at 2:46:17 PM UTC-7 Travis Scrimshaw wrote:
>
> I am *very* strongly opposed to these tags. Their cutoffs are arbitrary 
> nor they serve no useful purpose as far as I can tell. To this point, they 
> do not reflect the difficulty of a review; in fact, they are at best 
> counterproductive to finding reviewers because it might deter people from 
> reviewing "large" or "huge" changes as they can include lots of trivial 
> doctest changes. At best it is just additional clutter in all of the 
> information for PRs.
>
> From a community perspective, I feel such changes should have been brought 
> to the attention of sage-devel once the PR was at a positive review. 
> Specifically, *before* the PR was merged. Not everyone has time to read 
> every PR, and a small consensus of developers might not reflect the 
> development community at-large when making changes like this.
>
> Best,
> Travis
>
>
> On Tuesday, May 7, 2024 at 3:12:27 PM UTC+9 seb@gmail.com wrote:
>
> Dear Sage developers,
>
> You may have noticed that since yesterday a new type of labels with the 
> `v:` prefix has appeared on our PRs. These are automatically set to 
> classify PRs based on their size. For more information, see #37262 
> <https://github.com/sagemath/sage/pull/37262>.
>
> Sebastian
>
>

-- 
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/72772128-4ced-4e00-9ac6-7993bf7fa6f3n%40googlegroups.com.

Re: [sage-devel] Re: New labels v: mimimal, v: small ... on pull requests

[seb....@gmail.com]

I must confess that I have not thought about the aspects of these labels 
that Travis points out, but I fully understand these concerns. If they are 
annoying for many developers, the feature can be easily disabled by 
removing corresponding variables from the repository.


Vincent Delecroix schrieb am Freitag, 10. Mai 2024 um 07:45:13 UTC+2:

> I fully agree with Travis. I do not see the added value of these
> additional tags.
>
> On Thu, 9 May 2024 at 23:46, Travis Scrimshaw  wrote:
> >
> > I am *very* strongly opposed to these tags. Their cutoffs are arbitrary 
> nor they serve no useful purpose as far as I can tell. To this point, they 
> do not reflect the difficulty of a review; in fact, they are at best 
> counterproductive to finding reviewers because it might deter people from 
> reviewing "large" or "huge" changes as they can include lots of trivial 
> doctest changes. At best it is just additional clutter in all of the 
> information for PRs.
> >
> > From a community perspective, I feel such changes should have been 
> brought to the attention of sage-devel once the PR was at a positive 
> review. Specifically, before the PR was merged. Not everyone has time to 
> read every PR, and a small consensus of developers might not reflect the 
> development community at-large when making changes like this.
> >
> > Best,
> > Travis
> >
> >
> > On Tuesday, May 7, 2024 at 3:12:27 PM UTC+9 seb@gmail.com wrote:
> >>
> >> Dear Sage developers,
> >>
> >> You may have noticed that since yesterday a new type of labels with the 
> `v:` prefix has appeared on our PRs. These are automatically set to 
> classify PRs based on their size. For more information, see #37262.
> >>
> >> Sebastian
> >
> > --
> > 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/a1904934-a31f-4ce0-83c2-76cf2d1a70f1n%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/d09d6718-ba19-4420-9b94-2fdd722bdc72n%40googlegroups.com.

[sage-devel] New labels v: mimimal, v: small ... on pull requests

[seb....@gmail.com]

Dear Sage developers,

You may have noticed that since yesterday a new type of labels with the 
`v:` prefix has appeared on our PRs. These are automatically set to 
classify PRs based on their size. For more information, see #37262 
.

Sebastian

-- 
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/970aed50-44ff-48dd-92c9-31ba281fa061n%40googlegroups.com.

Re: [sage-devel] VOTE: Revert merged PR with unreviewed dependencies

[seb....@gmail.com]

Sure! But the fact was that reviewers objected to a commit in PR A that was 
approved in PR B, so their objection was simply ignored! Please don't 
understand me wrong. I'm not saying that it was your responsibility. It is 
still the responsibility of the reviewers to make sure that this does not 
happen. Probably this has become a bit harder since we moved to GitHub.

Volker Braun schrieb am Freitag, 26. April 2024 um 00:42:46 UTC+2:

> On Tuesday, April 23, 2024 at 6:24:51 PM UTC+2 seb....@gmail.com wrote:
>
> The problem with this is: if there are commits on a branch that are 
> reviewed in more than one PR, the question is: does *positive review* 
> mean *all* or *some* PR's?
>
>
> The review is for a single PR, not for individual commits.
>
> The positively reviewed PR gets merged, and then you may or may not want 
> to rebase other PRs on the new develop branch. If you do, then the changes 
> that were merged disappear from the "files changed" tab of that other PR on 
> github. Either way, the commits from the positively reviewed PR are added 
> to the sage codebase.
>
>

-- 
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/51ae610f-7527-4581-93bb-dc092f8bfc4bn%40googlegroups.com.

Re: [sage-devel] VOTE: Revert merged PR with unreviewed dependencies

[seb....@gmail.com]

> *Just go with how github works, which is positive review = ready to merge 
and "files changed" shows the actual changes that this PR implements.*

The problem with this is: if there are commits on a branch that are 
reviewed in more than one PR, the question is: does *positive review* mean 
*all* or *some* PR's? I don't think *some* is a good choice. Unfortunately, 
I don't have the time to read through all these controversial PR's at the 
moment. However, what I have seen is that every dispute started with one 
participant feeling ignored by others. Maybe this is enforced by written 
communication. But, if we allow a procedure that systematically ignores the 
opinions of some reviewers, we may be adding fuel to the fire.

Therefore I would have voted +1 if I hadn't missed the deadline. Like 
Travis, my vote is independent of the content of #36964.

Volker Braun schrieb am Samstag, 20. April 2024 um 11:04:24 UTC+2:

> It was merged because it was positively reviewed. 
>
> Neither I nor the merge script reads every ticket description and looks 
> through the text whether any dependency is mentioned that has not yet been 
> reviewed. We can try to build such a Rube Goldberg machine, but I would 
> very much argue against it. Just go with how github works, which is 
> positive review = ready to merge and "files changed" shows the actual 
> changes that this PR implements. Anything else will just prevent us from 
> using standard tooling in the future. If anything introduce a "preliminary 
> positive review" tag that gets replaced with actual positive review when 
> the dependencies are in.
>
> On Friday, April 19, 2024 at 9:50:35 AM UTC+2 Travis Scrimshaw wrote:
>
>> +1 for merging #37796.
>>
>> Volker, I would appreciate if you could say something about how #36964 
>> was merged. It would be useful to understand the process with merging this, 
>> rather than guessing the intent. Additionally, I thought we didn't merge 
>> things when the dependencies have not been merged (or merged 
>> simultaneously)? (This is why I am voting for reverting.)
>>
>> Best,
>> Travis
>>
>> On Friday, April 19, 2024 at 9:57:25 AM UTC+9 G. M.-S. wrote:
>>
>>>
>>> -1
>>>
>>> If something has been done that should be undone, I very much trust 
>>> Volker to take care of it when he can, without the need for endless 
>>> time-consuming discussions and votes.
>>>
>>> Best,
>>>
>>> Guillermo
>>>
>>> On Thu, 18 Apr 2024 at 17:54, David Roe  wrote:
>>>
 Hi all,
 Sage has had a review process for over 15 years, but a combination of 
 recent changes has led to the merging of a PR into sage-10.4.beta3 of a 
 change (#36964 ) that I 
 believe should not (yet) have been merged.  In #37796 
  I created a PR to revert 
 the change, which was opposed by the author of the original change.  After 
 some 
 voting 
  
 using the disputed PR policy 
 , 
 Matthias has asked 
  
 for a vote on sage-devel about this reversion, in accordance with the 
 section that "This process is intended as a lower-intensity method for 
 resolving disagreements, and full votes on sage-devel override the process 
 described below."  I am therefore asking you to vote (+1 means merge 
 #37796  in order to 
 revert #36964 ).

 First, here are the relevant parts of the history of this particular 
 change:

 - #36964  was created on 
 December 25 by Matthias, positively reviewed 
  
 by Kwankyu on Decemebr 27, disputed, received enough votes 
  
 to get a positive review on April 7, and was merged 
  
 by Volker on April 12.  It had dependencies: #37667, 
 #36951 
 , and #36676 
 .  While #37667 
  had positive review and 
 was already been merged, the other two were still disputed: they had 
 received an initial positive review but others objected and discussion was 
 ongoing.

 - #37667  is not disputed.

 - #36951  was created on 
 December 23 by Matthias, positively reviewed 
 

[sage-devel] Re: Vote: changes to Sage's Code of Conduct

[seb....@gmail.com]

+1

Marc Culler schrieb am Freitag, 22. März 2024 um 15:55:20 UTC+1:

> +1
>
> On Thursday, March 21, 2024 at 11:51:40 AM UTC-5 John H Palmieri wrote:
>
>> Dear Sage community,
>>
>> As announced at 
>> https://groups.google.com/g/sage-devel/c/Xf6dbPLmKPY/m/p88auKlBAwAJ, I 
>> propose some changes to the Code of Conduct. Those changes have been 
>> discussed and modified based on feedback from several developers: visit 
>> https://github.com/sagemath/sage/pull/37501 for details. Those changes 
>> are now ready for a vote here on sage-devel. 
>>
>> Please vote: do you approve the changes to the Code of Conduct proposed 
>> at https://github.com/sagemath/sage/pull/37501? Please vote on or before 
>> March 31.
>>
>> In case you want a summary: the old code of conduct was pretty short, so 
>> some details were added, and whole new sections were added. The proposed 
>> changes were greatly inspired by similar documents from the SciPy and 
>> NumFOCUS projects, and the proposed code now includes sections on 
>> diversity, how to report potential violations,  names of the committee 
>> members, and what is necessary to amend the document. There is also a new 
>> document, a manual for the Code of Conduct Committee, which describes what 
>> that committee does and what actions it might take to respond to reports. 
>> That document is a modified version of SciPy's corresponding document.
>>
>> -- 
>> 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/4876cd47-f54f-4496-9601-509cf20b6d93n%40googlegroups.com.

Re: [sage-devel] VOTE: disputed PRs

[seb....@gmail.com]

+1

David Lowry-Duda schrieb am Samstag, 9. März 2024 um 00:18:12 UTC+1:

> +1
>
> - DLD
>
> On 03:23 Mon 04 Mar 2024, David Roe wrote:
> >With no further discussion on this thread
> >, I'm calling a 
> vote
> >on a new process for resolving disagreements on a PR.
> >
> >*Proposal*
> >It is now allowed to vote on disputed PRs directly on Github rather than
> >bringing them to sage-devel. Working things out amicably is preferable,
> >and anyone is welcome to ask on sage-devel for more eyes on a PR. If you
> >notice a serious issue with a PR, it is acceptable to change it to Needs
> >Work (and make a comment!) as an initial step, but if the author or
> >reviewer do not agree then process below should be followed instead. This
> >process is intended as a lower-intensity method for resolving
> >disagreements, and full votes on sage-devel override the process described
> >below.
> >a. When there is disagreement about whether a PR should be merged, anyone
> >may mark a PR as disputed.
> >b. There is no scheduled vote, but rather an ongoing poll based on 
> opinions
> >expressed by developers on the PR (these opinions can be expressed via
> >previous positive reviews or explicit comments giving approval). The PR
> >author is presumed to vote in favor; if they give up or no longer favor 
> the
> >PR they have the right to close the PR overall without any further voting.
> >c. If the total number of positive votes is at least twice the number of
> >negative votes, anyone involved may set the status to *positive review*; 
> if
> >the total number of positive votes is less than twice the number of
> >negative votes, anyone involved may set the status to *needs review*. When
> >either of these actions is taken, the person changing the status must list
> >the people they are counting as positive and negative votes in a comment
> >using @ mentions.
> >d. The final decision on merging a disputed PR remains with the release
> >manager, and we encourage the release manager to give enough time for
> >everyone to express an opinion.
> >
> >Voting will be open until Wednesday, March 13.
> >David
> >
> >-- 
> >You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> >To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+...@googlegroups.com.
> >To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAChs6_n4az3_s16E%3DANOv_o%2B0SvavHwnpqKWYuOznGWTJoXqEg%40mail.gmail.com
> .
>
> -- 
> David Lowry-Duda  
>

-- 
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/dba73af4-4996-4357-bdee-b64944f73bcan%40googlegroups.com.

Re: [sage-devel] Re: Sage's Code of Conduct: proposed changes

[seb....@gmail.com]

Personally I don't mind if a maintainer would correct my typos in the PR 
description (or something else according to Volker's white list). However, 
since this is a privileged action and we cannot be sure that everyone feels 
this way, I think this point should be addressed generally. Perhaps the 
Code of Conduct could specify that permissions for cloud services that are 
technically necessary to maintain the project should generally not be used 
for other purposes unless there is agreement from all affected persons.

David Roe schrieb am Sonntag, 10. März 2024 um 16:44:06 UTC+1:

> I agree with both Tobias and Matthias that we should have a discussion 
> about the roles of maintainers (since they have defined privileges on 
> github) and changes to Sage's governance model more generally.  Martin and 
> Tobias have commented on trying to include some additional principles into 
> the code of conduct, and I've asked John to include my revised suggestion 
> into the PR .  This doesn't 
> currently address all of Martin's points, so if anyone has other concrete 
> changes to suggest feel free to do it here or on the PR.
>
> In the interest of moving forward, I'm planning on giving the PR positive 
> review on Thursday.  Of course, additional changes are always possible 
> through a discussion here if we find that there are more that we want to 
> add.
> David
>
> On Tue, Mar 5, 2024 at 2:45 PM Matthias Koeppe  
> wrote:
>
>> I think it's important to point out that a "Code of Conduct" is merely 
>> one document, of limited scope and purpose.
>>
>> In particular it does not touch matters of *governance* of a project. 
>> Open source projects with very different governance structures can share 
>> the same Code of Conduct.
>>
>> Questions such as "who can / should set status labels", "who can / should 
>> edit others' Issue/PR descriptions", etc. are primarily questions of 
>> governance, namely of *roles* in a project (and the associated duties 
>> and privileges of people in the role).
>>
>> This is a discussion that the project also needs to have quite urgently, 
>> but I suggest to get to this after the vote on the Code of Conduct and the 
>> appointment of the new CoC committee.
>>
>> Matthias
>>
>> On Friday, March 1, 2024 at 2:49:37 AM UTC-8 Martin R wrote:
>>
>>> I would like to ask whether we might want to add some of the following 
>>> to the code of conduct, I could not find it covered there.
>>>
>>> I admit that it is unclear to me whether the discussion should be on 
>>> pull requests only.  I don't want to add the following to John's pull 
>>> request, because it definitely doesn't belong there.  Opening another one 
>>> makes things even harder to follow, so I'm trying to be brave.
>>>
>>> I imagine that the issues below may be cultural things, so I would 
>>> perfectly understand that all or some of it is perfectly OK in some 
>>> communities, and therefore should not be part of the sage code of conduct.
>>>
>>> I also admit that some of the issues below are attitudes that make it 
>>> hard for me to work on sage.  There were some situations in which I would 
>>> possibly have stopped contributing to sage, if sage wasn't a professional 
>>> necessity for me.
>>>
>>> 0. sage is a community effort, and not the project of a single or even a 
>>> few persons.  Try to not identify yourself with the code in sage.
>>> 1. It is not OK to judge somebody else's attempts to improve sage other 
>>> than critisising it technically or casting a negative vote.  By contrast, 
>>> emphasising the positive aspects and appreciating the effort is welcome.
>>> 2. It is not OK to emphasise oneselves contributions or stressing that 
>>> one has been right.  By contrast, it is fine to express that one is happy 
>>> or perhaps even proud to have solved a particular technical problem.
>>> 3. It is not OK to modify the description of a pull request or issue of 
>>> somebody else without explicit permission, ideally on the ticket so that 
>>> the permission is visible to all readers.
>>> 4. It is not OK to change a pull request to "positive review" if someone 
>>> has already expressed explicitly that it shouldn't be merged, and there 
>>> hasn't been a vote.
>>>
>>> Comments and variations, but also saying that this should not be 
>>> discussed for a particular reason: welcome!
>>>
>>> Best wishes,
>>>
>>> Martin
>>> On Wednesday 28 February 2024 at 22:24:29 UTC+1 John H Palmieri wrote:
>>>
 Dear colleagues,

 I am working on some changes to Sage's Code of Conduct, and I am asking 
 for comments. Once the draft has stabilized, then we will hold a vote on 
 sage-devel to approve (or not) the changes. Please visit 
 https://github.com/sagemath/sage/pull/37501 to see the proposal.

 The current Code of Conduct was approved by a vote in sage-devel almost 
 10 years ago. My intention is not to alter the core principles in the Code 
 of Conduc

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

[seb....@gmail.com]

+1

Eric Gourgoulhon schrieb am Sonntag, 10. März 2024 um 16:58:42 UTC+1:

> +1
>
> Eric.
>
>

-- 
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/d35c59ad-b5a6-4fb7-9a2f-8d0adc238ce3n%40googlegroups.com.

[sage-devel] Re: One year of Sage development on GitHub

[seb....@gmail.com]

> *Is this selective activation possible?*

No! Activating the *labelled trigger* effects all state and priority 
labels. Even if restriced to the label s: needs review it could be affected 
by the GitHub bug, since the bot will remove a previously selected state 
label.

> *Sorry. This one is also affected by the github bug. Right?*

Yes!


Kwankyu Lee schrieb am Mittwoch, 21. Februar 2024 um 00:47:24 UTC+1:

>
> If a draft is marked as *ready for review* the s: needs review label is 
> added.
>
>
> Activate immediately. 
>
>
> Sorry. This one is also affected by the github bug. Right? 
>
> If so, not activate. 
>

-- 
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/f61abc85-9f2a-40b0-9f04-b83576884328n%40googlegroups.com.

[sage-devel] Re: One year of Sage development on GitHub

[seb....@gmail.com]

It must be done by a maintainer of the repository (see the desription of 
SYNC_LABELS_IGNORE_EVENTS in  #35172 
<https://github.com/sagemath/sage/pull/35172#issue-1595552799>). However, 
the restriction regarding the error in the web interface must then be 
accepted.


Matthias Koeppe schrieb am Dienstag, 20. Februar 2024 um 19:22:19 UTC+1:

> On Tuesday, February 20, 2024 at 10:11:14 AM UTC-8 seb@gmail.com 
> wrote:
>
> can be activated immediately: If a user converts a ready PR to a draft, 
> all status labels will be removed. If a draft is marked as *ready for 
> review* the s: needs review label is added. Also implemented (but not 
> activated): If the s: needs review label is added a draft PR, it is 
> marked as *ready for review*.
>
>
> Sounds good to me, let's do 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/794f21a5-6209-4d33-b78d-36dbff290d34n%40googlegroups.com.

[sage-devel] Re: One year of Sage development on GitHub

[seb....@gmail.com]

This is currently not implemented, but of course possible. But the converse 
can be activated immediately: If a user converts a ready PR to a draft, all 
status labels will be removed. If a draft is marked as *ready for review* 
the s: needs review label is added. Also implemented (but not activated): 
If the s: needs review label is added a draft PR, it is marked as *ready 
for review*.

Matthias Koeppe schrieb am Dienstag, 20. Februar 2024 um 04:26:50 UTC+1:

> On Monday, February 19, 2024 at 7:02:26 PM UTC-8 Kwankyu Lee wrote:
>
>
> *3. Are the labels on GitHub Issues / PRs helpful?*
> - Note that new contributors who are not in the Triage team cannot 
> set/change labels! 
> - This includes component labels, but also status labels such as "needs 
> review".
>
>
> We may drop "needs review" label, and start to use github "draft" 
> functionality. This will remove one major obstacle for new contributors.
>
>
> I would support this.
>
> Can the status label sync workflow help with this transition, without 
> getting in the way? For example, when the _author_ removes the "needs 
> review" label (without setting "positive review"), set the PR to "draft"? 
>
>
>

-- 
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/f040e4e1-d5a3-4f77-a2e2-7d2dddbadd0an%40googlegroups.com.

Re: [sage-devel] Re: One year of Sage development on GitHub

[seb....@gmail.com]

The bot uses gh edit to manipulate the labels (see the code here 
<https://github.com/sagemath/sage/blob/30b3d78fac8d4a015ad2641cad44c3d530f4c10c/.github/sync_labels.py#L745>).
 
AFAIR I also tried with gh api leading to the same behavior in the web 
interface. In principle these commands work, but the result is not visible 
until you add or edit a comment or refresh the web-page.


*> (by the way, your bug reports are not visible - probably only visible to 
you.*

Thanks for the hint. I've uploaded screen-shots in the header of a 
corresponding PR 36292 
<https://github.com/sagemath/sage/pull/36292#issue-1900238183>. Here some 
citations of the respond:

December 4th:




*The good news is, our team is already working on a suite of improvements 
to the issues and pull requests experience and this will be resolved as 
result of those changes.Unfortunately I can't share too much about the 
details as it's still being tested internally, but you can keep an eye on 
our changelog for any updates.Thanks for your feedback and I hope this 
quirk doesn't bother your team too much in the meantime.*

February 8th (from the second report where I asked for a status report):





*Thanks for following up. Our engineering team are working on a complete 
overhaul of the issues experience - I've confirmed that this bug is already 
resolved in the new version.I can understand it's frustrating seeing this 
bug persist, but given its upcoming replacement, bug fixes for the current 
issues experience are limited to critical issues that have a significant 
impact. The overhaul is in progress and unfortunately hasn't been publicly 
announced which limits how much detail I can share. I'd suggest keeping an 
eye on our roadmap and changelog for updates.I'm sorry for any 
inconvenience, and please let me know if you have any questions.*

Dima Pasechnik schrieb am Dienstag, 20. Februar 2024 um 00:21:32 UTC+1:

> On Mon, Feb 19, 2024 at 9:20 PM seb@gmail.com  
> wrote:
>
>>  > *Is it time for the next step with syncing status labels 
>> (https://github.com/sagemath/sage/issues/35927 
>> <https://github.com/sagemath/sage/issues/35927>)? *
>>
>> The reason this is blocked is because there is a bug in the GitHub web 
>> interface that might cause confusion when labels are added or removed by 
>> the bot. More precisely, the panel with labels is not updated immediately 
>> after such an action. I have opened two bug reports (2448092 
>> <https://support.github.com/ticket/personal/0/2448092>, 2573072 
>> <https://support.github.com/ticket/personal/0/2573072>). Both were 
>> closed without a satisfactory answer, only informing that it is a known bug 
>> that will be fixed one day.
>>
>
> As far as I know you have an API to manipulate github labels, e.g. it's 
> supported by gh.
> Is this what's used by the bot?
>
> (by the way, your bug reports are not visible - probably only visible to 
> you.
>
>
>>
>> Matthias Koeppe schrieb am Freitag, 16. Februar 2024 um 19:00:52 UTC+1:
>>
>>> On Thursday, February 8, 2024 at 10:16:58 AM UTC-8 Matthias Koeppe wrote:
>>>
>>> On Wednesday, February 7, 2024 at 1:11:14 PM UTC-8 Matthias Koeppe wrote:
>>>
>>> Let's also use this anniversary as an opportunity to discuss what still 
>>> needs improving in our development workflows. 
>>>
>>> *1. We have a low development velocity.* For example, some simple PRs 
>>> sit for weeks or months before receiving any review comments. What can we 
>>> do to improve this?
>>>
>>> *2. Is our community aware of the sagemath/sage GitHub wiki?* 
>>> https://github.com/sagemath/sage/wiki
>>> - Are the contents of the wiki front page useful?
>>> - Are the links to Issue and Pull Request queries helpful? 
>>>
>>>
>>> *3. Are the labels on GitHub Issues / PRs helpful?*
>>> - Note that new contributors who are not in the Triage team cannot 
>>> set/change labels! 
>>> - This includes component labels, but also status labels such as "needs 
>>> review".
>>> - Is it time for the next step with syncing status labels (
>>> https://github.com/sagemath/sage/issues/35927)?
>>> - Wishlist item: Component auto-labeler for GitHub PRs (
>>> https://github.com/sagemath/sage/issues/37373)
>>> - Wishlist item: PR size labeler (
>>> https://github.com/sagemath/sage/pull/37262)
>>>
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails 

[sage-devel] Re: One year of Sage development on GitHub

[seb....@gmail.com]

 > *Is it time for the next step with syncing status labels 
(https://github.com/sagemath/sage/issues/35927 
)? *

The reason this is blocked is because there is a bug in the GitHub web 
interface that might cause confusion when labels are added or removed by 
the bot. More precisely, the panel with labels is not updated immediately 
after such an action. I have opened two bug reports (2448092 
, 2573072 
). Both were closed 
without a satisfactory answer, only informing that it is a known bug that 
will be fixed one day.


Matthias Koeppe schrieb am Freitag, 16. Februar 2024 um 19:00:52 UTC+1:

> On Thursday, February 8, 2024 at 10:16:58 AM UTC-8 Matthias Koeppe wrote:
>
> On Wednesday, February 7, 2024 at 1:11:14 PM UTC-8 Matthias Koeppe wrote:
>
> Let's also use this anniversary as an opportunity to discuss what still 
> needs improving in our development workflows. 
>
> *1. We have a low development velocity.* For example, some simple PRs sit 
> for weeks or months before receiving any review comments. What can we do to 
> improve this?
>
> *2. Is our community aware of the sagemath/sage GitHub wiki?* 
> https://github.com/sagemath/sage/wiki
> - Are the contents of the wiki front page useful?
> - Are the links to Issue and Pull Request queries helpful? 
>
>
> *3. Are the labels on GitHub Issues / PRs helpful?*
> - Note that new contributors who are not in the Triage team cannot 
> set/change labels! 
> - This includes component labels, but also status labels such as "needs 
> review".
> - Is it time for the next step with syncing status labels (
> https://github.com/sagemath/sage/issues/35927)?
> - Wishlist item: Component auto-labeler for GitHub PRs (
> https://github.com/sagemath/sage/issues/37373)
> - Wishlist item: PR size labeler (
> https://github.com/sagemath/sage/pull/37262)
>
>
>

-- 
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/6745500d-2077-42b7-9406-d38c3e280407n%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels starts on Tuesday July 18th

[seb....@gmail.com]

I don't understand what you mean here. Can you please explain this in the 
new PR.

Kwankyu Lee schrieb am Montag, 18. September 2023 um 03:17:50 UTC+2:

> In a message of 
> https://github.com/sagemath/sage/pull/36020#issuecomment-1722629380, 
> please change to "state label" (or "status label" which I prefer) from 
> "state-label".
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2a4f172f-6bd3-43c0-9d90-4c82c11b6afan%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels starts on Tuesday July 18th

[seb....@gmail.com]

Yes. This will be done in PR #36292 
<https://github.com/sagemath/sage/pull/36292>.

Kwankyu Lee schrieb am Montag, 18. September 2023 um 03:07:14 UTC+2:

> On Friday, September 8, 2023 at 5:47:30 PM UTC+9 seb@gmail.com wrote:
>
> > I think this is too verbose. In particular, the message "kwankyu 
> requested changes for this PR" is redundant.
>
> From the point of view of a developer familiar with Trac status labels, I 
> agree. However, a key goal of the GitHub migration was to attract new 
> developers who are familiar with the GitHub workflow but have no knowledge 
> of Trac. The comment will show them that the label  s: needs work is used 
> as a synonym for request changes. However, note that the comment is the 
> body of the request changes review which cannot be omitted:
>
>
> OK. Shouldn't it be "@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/8aa64f02-b878-4e7d-9db1-975d9f57e63dn%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels starts on Tuesday July 18th

[seb....@gmail.com]

See the comment 
 in 
#36213 .

Kwankyu Lee schrieb am Montag, 18. September 2023 um 03:03:26 UTC+2:

> For a case where it's not done cleanly, see 
>
> https://github.com/sagemath/sage/pull/36020#issuecomment-1722629380
>

-- 
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/05188078-f5a4-4605-8059-516879500093n%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels starts on Tuesday July 18th

[seb....@gmail.com]

> Note that "github-actions[bot]" in Reviewers. What does this mean? I 
don't understand how this happened...
>
> Could this be somehow related with the recent synchronization turn-on?

Yes, since the GitHub state request-changes was not set before you add the s: 
needs work label the bot sets it for you. Of course it would be much nicer 
if the bot would set your name into the reviewer field (making the comment 
indeed redundant). But, this seems to be impossible (even via the REST API).

At the moment the labeled-trigger is disabled again by reasons indicated in 
Dima's post (for more information see this comment in #36177 
 and 
the following). I've opened PR #36213 
 to treat issues that have 
been observed in connection with the labeled event.



Kwankyu Lee schrieb am Sonntag, 3. September 2023 um 14:28:43 UTC+2:

> Note that "github-actions[bot]" in Reviewers. What does this mean? I don't 
> understand how this happened...
>
>  Could this be somehow related with the recent synchronization turn-on?
>
>
> 
>
> [image: Screenshot 2023-09-03 at 9.23.20 PM.png]
>
> On Sunday, September 3, 2023 at 2:54:20 PM UTC+9 Kwankyu Lee wrote:
>
>> Thanks.
>>
>> I noticed one defect (nothing serious). For "closed" event, the message 
>> is succinct. 
>> ---
>>
>> [image: Screenshot 2023-09-03 at 2.43.25 PM.png]
>> ---
>> Now for adding status label ("s: needs work"), the message is 
>> ---
>> [image: Screenshot 2023-09-03 at 2.48.07 PM.png]
>> ---
>> I think this is too verbose. In particular, the message "kwankyu 
>> requested changes for this PR" is redundant. 
>>
>

-- 
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/d8783c93-d1e2-4c20-b705-46622139b7c8n%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels starts on Tuesday July 18th

[seb....@gmail.com]

> I think this is too verbose. In particular, the message "kwankyu 
requested changes for this PR" is redundant.

>From the point of view of a developer familiar with Trac status labels, I 
agree. However, a key goal of the GitHub migration was to attract new 
developers who are familiar with the GitHub workflow but have no knowledge 
of Trac. The comment will show them that the label  s: needs work is used 
as a synonym for request changes. However, note that the comment is the 
body of the request changes review which cannot be omitted:


gh pr review 35172 -r
body cannot be blank for request-changes review


Kwankyu Lee schrieb am Sonntag, 3. September 2023 um 07:54:20 UTC+2:

> Thanks.
>
> I noticed one defect (nothing serious). For "closed" event, the message is 
> succinct. 
> ---
>
> [image: Screenshot 2023-09-03 at 2.43.25 PM.png]
> ---
> Now for adding status label ("s: needs work"), the message is 
> ---
> [image: Screenshot 2023-09-03 at 2.48.07 PM.png]
> ---
> I think this is too verbose. In particular, the message "kwankyu requested 
> changes for this PR" is redundant. 
>

-- 
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/9e5fa9cf-d947-4d13-8b69-99769146a8bdn%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels starts on Tuesday July 18th

[seb....@gmail.com]

Tobias activated the functionality today (see 
https://github.com/sagemath/sage/issues/35927#issuecomment-1703696369).

Kwankyu Lee schrieb am Freitag, 1. September 2023 um 22:36:56 UTC+2:

> How is this going?
>
> On Friday, August 4, 2023 at 1:54:13 AM UTC+9 seb@gmail.com wrote:
>
>> I've added a comment 
>> <https://github.com/sagemath/sage/issues/35927#issuecomment-1664313362> 
>> to issue #35927 <https://github.com/sagemath/sage/issues/35927> to 
>> enable a next step accordingly. More information about what will change in 
>> this step can be found there.
>>
>>
>> Kwankyu Lee schrieb am Donnerstag, 3. August 2023 um 01:23:16 UTC+2:
>>
>>> Personally, I want the feature to keep at most one status(state) label 
>>> for a PR, so that if a person add a new status label (say "positive 
>>> review"), then the old one ("needs review") is automatically removed. 
>>> Currently it is annoying to do this manually.  
>>
>>

-- 
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/fd169f50-d4f4-4ce1-8615-c39d8e6cf9bdn%40googlegroups.com.

[sage-devel] Re: images lacking on docker hub

[seb....@gmail.com]

I've opened PR #36047 <https://github.com/sagemath/sage/pull/36047> which 
creates a GitHub workflow to produce the Docker Hub images automatically 
again.
seb....@gmail.com schrieb am Donnerstag, 20. Juli 2023 um 08:09:51 UTC+2:

> Releases 9.8 and 10.0 are available on DockerHub sagemath/sagemath 
> <https://hub.docker.com/repository/docker/sagemath/sagemath/general>, now. 
> The temporary repository soehms/sagemath I've removed again.  
>
> Frédéric Chapoton schrieb am Sonntag, 16. Juli 2023 um 16:39:31 UTC+2:
>
>> yes, stable versions would be good enough. And not too much work, 
>> hopefully. So, please ask Julian to be added to the sagemath organisation 
>> on dockerhub.
>>
>> Frederic
>>
>> Le dimanche 16 juillet 2023 à 13:38:47 UTC+2, seb@gmail.com a écrit :
>>
>>>
>>> I successfully built one for stable 10.0, two weeks ago using the 
>>> current version of the docker/Dockerfile following the instructions 
>>> given there (in section HOWTO use this file to manually create new 
>>> images for Docker Hub). I haven't really used it yet. However, Sage 
>>> 10.0 starts and works unless you try to use IPython magics (for example 
>>> ? to read the documentation). If you do that, it crashes (but so does 
>>> the 9.7 image). Yesterday I pushed that to my private Docker account. 
>>> Therefore, for the time being it can be used at your own risk via docker 
>>> run -it soehms/sagemath:10.0. I can try to do the same for 9.8.
>>>
>>> Frederic, would a restriction to the stable versions be acceptable to 
>>> you? I would like to have a continuation of the Docker images, too. But I 
>>> can relinquish development versions since for this use case there are other 
>>> alternatives, such as Gitpod. Maybe it would simplify things if we only 
>>> continued stable releases on DockerHub.
>>>
>>> Sebastian
>>> Frédéric Chapoton schrieb am Samstag, 15. Juli 2023 um 18:48:08 UTC+2:
>>>
>>>> Hello,
>>>>
>>>> Anybody with some docker expertise who would like to help us having 
>>>> up-to-date docker images on dockerhub ?
>>>>
>>>> Frederic
>>>>
>>>> Le jeudi 11 mai 2023 à 15:32:28 UTC+2, julian...@fsfe.org a écrit :
>>>>
>>>>> Btw., I recently applied for "Sponsored OSS" status on the Docker Hub 
>>>>> which was finally granted. So we can now have more then 3 user accounts 
>>>>> with write access (until now it was mkoeppe, a bot user and myself.) 
>>>>> Please 
>>>>> contact me if you want to be added as a maintainer.
>>>>>
>>>>> On Thursday, May 11, 2023 at 4:29:31 PM UTC+3 julian...@fsfe.org 
>>>>> wrote:
>>>>>
>>>>>> Sorry, I didn't see this thread.
>>>>>>
>>>>>> I do have the credentials for docker hub. I am happy to share them 
>>>>>> with anybody who wants to help with maintaining the docker images. (I 
>>>>>> don't 
>>>>>> use the docker images anymore myself so I do not really maintain them 
>>>>>> anymore. Also, the automatic infrastructure that we used to update them 
>>>>>> broke years ago which makes the process quite a bit of work. With each 
>>>>>> release of SageMath, something in the build process breaks typically. We 
>>>>>> could migrate this to GitHub workflows but it's also a fair amount of 
>>>>>> work 
>>>>>> and, again since I am not using the images, I don't feel very motivated 
>>>>>> to 
>>>>>> champion that process.)
>>>>>>
>>>>>> julian
>>>>>>
>>>>>> On Thursday, May 11, 2023 at 3:27:20 PM UTC+3 Frédéric Chapoton wrote:
>>>>>>
>>>>>>> asking again : who has the rights for the docker user 
>>>>>>> *sagemathadmins* ?
>>>>>>>
>>>>>>> Frédéric
>>>>>>>
>>>>>>> Le dimanche 23 avril 2023 à 10:33:42 UTC+2, Frédéric Chapoton a 
>>>>>>> écrit :
>>>>>>>
>>>>>>>> There are some instructions for that at the top of our 
>>>>>>>> docker/Dockerfile. But I guess there is also a matter of rights, no ? 
>>>>>>>> Who 
>>>>>>>> is allowed to do that ? Maybe Julian ?
>>>>>>>>
>>>>>>>> Le mercredi 5 avril 2023 à 10:18:27 UTC+2, Frédéric Chapoton a 
>>>>>>>> écrit :
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> it seems that no recent image is available on docker hub:
>>>>>>>>>
>>>>>>>>> https://hub.docker.com/search?q=sagemath%2Fsage
>>>>>>>>>
>>>>>>>>> In particular, 9.8 is not there.
>>>>>>>>> Is there a way to manually update that, if there is no automatic 
>>>>>>>>> mechanism to do the job ?
>>>>>>>>>
>>>>>>>>> Frédéric
>>>>>>>>>
>>>>>>>>

-- 
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/0202e671-d95e-45c7-9e3e-91d0c1e1bd68n%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels starts on Tuesday July 18th

[seb....@gmail.com]

I've added a comment 
 to 
issue 
#35927  to enable a next 
step accordingly. More information about what will change in this step can 
be found there.


Kwankyu Lee schrieb am Donnerstag, 3. August 2023 um 01:23:16 UTC+2:

> Personally, I want the feature to keep at most one status(state) label for 
> a PR, so that if a person add a new status label (say "positive review"), 
> then the old one ("needs review") is automatically removed. Currently it is 
> annoying to do this manually.  

-- 
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/63e8eea1-48b6-464f-aa6a-c079aa607982n%40googlegroups.com.

[sage-devel] Re: images lacking on docker hub

[seb....@gmail.com]

Releases 9.8 and 10.0 are available on DockerHub sagemath/sagemath 
<https://hub.docker.com/repository/docker/sagemath/sagemath/general>, now. 
The temporary repository soehms/sagemath I've removed again.  

Frédéric Chapoton schrieb am Sonntag, 16. Juli 2023 um 16:39:31 UTC+2:

> yes, stable versions would be good enough. And not too much work, 
> hopefully. So, please ask Julian to be added to the sagemath organisation 
> on dockerhub.
>
> Frederic
>
> Le dimanche 16 juillet 2023 à 13:38:47 UTC+2, seb@gmail.com a écrit :
>
>>
>> I successfully built one for stable 10.0, two weeks ago using the current 
>> version of the docker/Dockerfile following the instructions given there 
>> (in section HOWTO use this file to manually create new images for Docker 
>> Hub). I haven't really used it yet. However, Sage 10.0 starts and works 
>> unless you try to use IPython magics (for example ? to read the 
>> documentation). If you do that, it crashes (but so does the 9.7 image). 
>> Yesterday I pushed that to my private Docker account. Therefore, for the 
>> time being it can be used at your own risk via docker run -it 
>> soehms/sagemath:10.0. I can try to do the same for 9.8.
>>
>> Frederic, would a restriction to the stable versions be acceptable to 
>> you? I would like to have a continuation of the Docker images, too. But I 
>> can relinquish development versions since for this use case there are other 
>> alternatives, such as Gitpod. Maybe it would simplify things if we only 
>> continued stable releases on DockerHub.
>>
>> Sebastian
>> Frédéric Chapoton schrieb am Samstag, 15. Juli 2023 um 18:48:08 UTC+2:
>>
>>> Hello,
>>>
>>> Anybody with some docker expertise who would like to help us having 
>>> up-to-date docker images on dockerhub ?
>>>
>>> Frederic
>>>
>>> Le jeudi 11 mai 2023 à 15:32:28 UTC+2, julian...@fsfe.org a écrit :
>>>
>>>> Btw., I recently applied for "Sponsored OSS" status on the Docker Hub 
>>>> which was finally granted. So we can now have more then 3 user accounts 
>>>> with write access (until now it was mkoeppe, a bot user and myself.) 
>>>> Please 
>>>> contact me if you want to be added as a maintainer.
>>>>
>>>> On Thursday, May 11, 2023 at 4:29:31 PM UTC+3 julian...@fsfe.org wrote:
>>>>
>>>>> Sorry, I didn't see this thread.
>>>>>
>>>>> I do have the credentials for docker hub. I am happy to share them 
>>>>> with anybody who wants to help with maintaining the docker images. (I 
>>>>> don't 
>>>>> use the docker images anymore myself so I do not really maintain them 
>>>>> anymore. Also, the automatic infrastructure that we used to update them 
>>>>> broke years ago which makes the process quite a bit of work. With each 
>>>>> release of SageMath, something in the build process breaks typically. We 
>>>>> could migrate this to GitHub workflows but it's also a fair amount of 
>>>>> work 
>>>>> and, again since I am not using the images, I don't feel very motivated 
>>>>> to 
>>>>> champion that process.)
>>>>>
>>>>> julian
>>>>>
>>>>> On Thursday, May 11, 2023 at 3:27:20 PM UTC+3 Frédéric Chapoton wrote:
>>>>>
>>>>>> asking again : who has the rights for the docker user 
>>>>>> *sagemathadmins* ?
>>>>>>
>>>>>> Frédéric
>>>>>>
>>>>>> Le dimanche 23 avril 2023 à 10:33:42 UTC+2, Frédéric Chapoton a 
>>>>>> écrit :
>>>>>>
>>>>>>> There are some instructions for that at the top of our 
>>>>>>> docker/Dockerfile. But I guess there is also a matter of rights, no ? 
>>>>>>> Who 
>>>>>>> is allowed to do that ? Maybe Julian ?
>>>>>>>
>>>>>>> Le mercredi 5 avril 2023 à 10:18:27 UTC+2, Frédéric Chapoton a 
>>>>>>> écrit :
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> it seems that no recent image is available on docker hub:
>>>>>>>>
>>>>>>>> https://hub.docker.com/search?q=sagemath%2Fsage
>>>>>>>>
>>>>>>>> In particular, 9.8 is not there.
>>>>>>>> Is there a way to manually update that, if there is no automatic 
>>>>>>>> mechanism to do the job ?
>>>>>>>>
>>>>>>>> Frédéric
>>>>>>>>
>>>>>>>

-- 
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/90f81e24-01e7-4864-8003-1e570fcd85c0n%40googlegroups.com.

[sage-devel] Re: images lacking on docker hub

[seb....@gmail.com]

I successfully built one for stable 10.0, two weeks ago using the current 
version of the docker/Dockerfile following the instructions given there (in 
section HOWTO use this file to manually create new images for Docker Hub). 
I haven't really used it yet. However, Sage 10.0 starts and works unless 
you try to use IPython magics (for example ? to read the documentation). If 
you do that, it crashes (but so does the 9.7 image). Yesterday I pushed 
that to my private Docker account. Therefore, for the time being it can be 
used at your own risk via docker run -it soehms/sagemath:10.0. I can try to 
do the same for 9.8.

Frederic, would a restriction to the stable versions be acceptable to you? 
I would like to have a continuation of the Docker images, too. But I can 
relinquish development versions since for this use case there are other 
alternatives, such as Gitpod. Maybe it would simplify things if we only 
continued stable releases on DockerHub.

Sebastian
Frédéric Chapoton schrieb am Samstag, 15. Juli 2023 um 18:48:08 UTC+2:

> Hello,
>
> Anybody with some docker expertise who would like to help us having 
> up-to-date docker images on dockerhub ?
>
> Frederic
>
> Le jeudi 11 mai 2023 à 15:32:28 UTC+2, julian...@fsfe.org a écrit :
>
>> Btw., I recently applied for "Sponsored OSS" status on the Docker Hub 
>> which was finally granted. So we can now have more then 3 user accounts 
>> with write access (until now it was mkoeppe, a bot user and myself.) Please 
>> contact me if you want to be added as a maintainer.
>>
>> On Thursday, May 11, 2023 at 4:29:31 PM UTC+3 julian...@fsfe.org wrote:
>>
>>> Sorry, I didn't see this thread.
>>>
>>> I do have the credentials for docker hub. I am happy to share them with 
>>> anybody who wants to help with maintaining the docker images. (I don't use 
>>> the docker images anymore myself so I do not really maintain them anymore. 
>>> Also, the automatic infrastructure that we used to update them broke years 
>>> ago which makes the process quite a bit of work. With each release of 
>>> SageMath, something in the build process breaks typically. We could migrate 
>>> this to GitHub workflows but it's also a fair amount of work and, again 
>>> since I am not using the images, I don't feel very motivated to champion 
>>> that process.)
>>>
>>> julian
>>>
>>> On Thursday, May 11, 2023 at 3:27:20 PM UTC+3 Frédéric Chapoton wrote:
>>>
 asking again : who has the rights for the docker user *sagemathadmins* 
 ?

 Frédéric

 Le dimanche 23 avril 2023 à 10:33:42 UTC+2, Frédéric Chapoton a écrit :

> There are some instructions for that at the top of our 
> docker/Dockerfile. But I guess there is also a matter of rights, no ? Who 
> is allowed to do that ? Maybe Julian ?
>
> Le mercredi 5 avril 2023 à 10:18:27 UTC+2, Frédéric Chapoton a écrit :
>
>> Hello,
>>
>> it seems that no recent image is available on docker hub:
>>
>> https://hub.docker.com/search?q=sagemath%2Fsage
>>
>> In particular, 9.8 is not there.
>> Is there a way to manually update that, if there is no automatic 
>> mechanism to do the job ?
>>
>> Frédéric
>>
>

-- 
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/2ea451d6-c0d6-4b43-8c49-6c5283286e15n%40googlegroups.com.

[sage-devel] Re: Download-statistics of Sage related PyPI packages

[seb....@gmail.com]

I have now uploaded a final update of the data to DBhub.io. There are 6 
projects more and the content is up to July 12th. Repeating the query above 
for the last two months yields:

select python, sum(num_downloads) num_downloads from sage_pypi_packages 
where date > '2023-04-30' and installer in ('pip', 'Browser') and python 
NOT NULL group by python order by 2 desc

python  num_downloads
-
3.9.5   36314
3.7.16  26468
3.8.16  18956
3.8.10  17842
3.9.16  16237
3.8.17  12544
3.10.11 8525
3.7.4   6256
3.7.17  5813
3.9.2   5443
3.6.12  5420
3.10.12 5139
3.10.6  4758
3.9.17  4673
3.9.6   4631
3.11.3  4626
3.7.5   4365
3.9.7   3178
3.10.8  2275
3.11.2  2187
3.11.4  2168
3.9.15  1941
3.8.12  1912
3.8.0   1893
3.10.10 1850
2.7.16  1554
3.9.13  1485
3.10.5  1345
3.11.1  1244
3.8.13  1093
3.6.8   1065
3.10.9  1016
2.7.18  942



seb@gmail.com schrieb am Samstag, 27. Mai 2023 um 00:20:09 UTC+2:

> I queried such data stored between January 2016 and April 2023 and put it 
> into a read-only SQLite database. If you're interested, check out this DBHub 
> database <https://dbhub.io/soehms/sagemath_related_pypi_downloads.db>. 
> Scroll down to read how to visualize the data.
>
> I used a Google free trial service account 
> <https://cloud.google.com/free/docs/free-cloud-features#free-trial> for 
> this. I plan on extracting some more data (and then happily escaping the 
> lion's den) before the July expiration. So if you are the maintainer of a 
> project that is now missing, adding the *SageMath* keyword to the PyPI 
> repository before July will add it. Alternatively, you can also report this 
> on the discussion-chanel on DBHub.
>
>
> Concerning the discussion in the NEP29 thread, I think the following query 
> is interesting:
>
> select python, sum(num_downloads) num_downloads from sage_pypi_packages 
> where date > '2023-02-28' and installer in ('pip', 'Browser') and python 
> NOT NULL group by python order by 2 desc
>
> python  num_downloads
> -
> 3.8.10  13301
> 3.9.5   13207
> 3.9.16  12371
> 3.8.16  11158
> 3.7.16  7309
> 3.10.10 4085
> 3.7.4   3847
> 3.7.10  3502
> 3.7.5   2771
> 3.11.2  2723
> 3.10.6  2082
> 3.10.8  2027
> 3.9.13  1684
> 3.10.11 1660
> 3.10.9  1495
> 3.8.12  1415
> 3.7.12  1308
> 3.7.15  1161
> 3.9.2   1123
> 3.9.15  1121
> 3.7.11  866
> ...
>
>

-- 
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/4120e830-60b1-4d5a-a4f1-7e5fda7f9771n%40googlegroups.com.

[sage-devel] Synchronization of GitHub state and priority labels starts on Tuesday July 18th

[seb....@gmail.com]

Dear Sage developers,


Now, it's five months ago that the migration from Trac to GitHub happened. 
Many of us became familiar with the new workflows and probably found their 
own ways to use them. From this point of view it seems a little bit late to 
introduce a new feature to make the workflow more convenient. Convenience 
isn't the sole purpose of label sync, however. It will also keep our PR's 
and issues in an unambiguous state.

The bot will be activated in several steps. These are tracked in issue 
#35937 . The first step 
activates the bot on the close event of a PR. This will happen next 
Tuesday. Please post any comments, suggestions and bug reports to this 
issue.


Sebastian

-- 
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/ff34d807-66bf-4f9c-8d61-2d8e3b866f82n%40googlegroups.com.

Re: [sage-devel] Re: Voting: Block-scoped optional tag and the keyword

[seb....@gmail.com]

I vote for (C)

David Roe schrieb am Donnerstag, 29. Juni 2023 um 17:57:35 UTC+2:

> I vote for (A)
>
> On Thu, Jun 29, 2023 at 5:13 AM Eric Gourgoulhon  
> wrote:
>
>> I vote for (A)
>>
>
>> -- 
>> 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/1931486a-b228-402b-b2b7-42945e3fd18dn%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/9c7efc41-e3b4-4c1e-8f1f-ef6d75d4d9c7n%40googlegroups.com.

[sage-devel] Download-statistics of Sage related PyPI packages

[seb....@gmail.com]

I queried such data stored between January 2016 and April 2023 and put it 
into a read-only SQLite database. If you're interested, check out this DBHub 
database . 
Scroll down to read how to visualize the data.

I used a Google free trial service account 
 for 
this. I plan on extracting some more data (and then happily escaping the 
lion's den) before the July expiration. So if you are the maintainer of a 
project that is now missing, adding the *SageMath* keyword to the PyPI 
repository before July will add it. Alternatively, you can also report this 
on the discussion-chanel on DBHub.


Concerning the discussion in the NEP29 thread, I think the following query 
is interesting:

select python, sum(num_downloads) num_downloads from sage_pypi_packages 
where date > '2023-02-28' and installer in ('pip', 'Browser') and python 
NOT NULL group by python order by 2 desc

python  num_downloads
-
3.8.10  13301
3.9.5   13207
3.9.16  12371
3.8.16  11158
3.7.16  7309
3.10.10 4085
3.7.4   3847
3.7.10  3502
3.7.5   2771
3.11.2  2723
3.10.6  2082
3.10.8  2027
3.9.13  1684
3.10.11 1660
3.10.9  1495
3.8.12  1415
3.7.12  1308
3.7.15  1161
3.9.2   1123
3.9.15  1121
3.7.11  866
...

-- 
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/b11ecb46-d378-4d62-a3dd-3d3d2030c580n%40googlegroups.com.

[sage-devel] Re: Knot theory: Change PD-code convention

[seb....@gmail.com]

PR #35665 <https://github.com/sagemath/sage/pull/35665> implementing the 
convention change is now available for review. 


seb@gmail.com schrieb am Freitag, 24. Februar 2023 um 17:48:35 UTC+1:

> Hi everybody,
>
> The PD (Planar Diagram) notation is one of the most important concepts to 
> define a knot or link uniquely (besides the braid notation). Unfortunately 
> our convention on how to read the four strands meeting at a crossing is 
> opposite to the one used in most other places: We read them in clockwise 
> direction whereas most others do it anti-clockwise.
>
> I've started a discussion in issue #17030 
> <https://github.com/sagemath/sage/issues/17030> (the ticket that 
> introduced knot theory in Sage in 2014) to change our convention 
> accordingly (starting from this comment 
> <https://github.com/sagemath/sage/issues/17030#issuecomment-1429244168>).
>
> If you have objections to this, please comment there!
>
> Sebastian
>

-- 
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/c1087cc4-3835-47c2-b1d4-8d861466e950n%40googlegroups.com.

[sage-devel] Re: Sage developer's guide

[seb....@gmail.com]

This PR is ready for review, now!

Kwankyu Lee schrieb am Mittwoch, 5. April 2023 um 10:28:22 UTC+2:

It seems like that banner could be updated a bit, now that it is April. 

I do realize that there's still a lot being hashed out about the exact 
workflow...


It seems that the workflow is still in flux. Some questions: 

.

(6) What to do with automatic labelling vs manual labelling? 
https://github.com/sagemath/sage/pull/35172

 

-- 
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/43107091-2f0e-48ec-9e22-6ef5e3b8d033n%40googlegroups.com.

[sage-devel] Sync labels with GitHub states by a bot

[seb....@gmail.com]

Hello everyone,


More than a month has passed since we migrated to GitHub. As you explored 
the new workflows, you may have noticed that there are some redundancies 
regarding a PR's status. On the one hand there are states supported by 
GitHub to mark a PR as draft or approved... on the other hand there are 
labels migrated from Trac that show almost the same thing (s: need review, 
s : positive_review . ..).

The need to have them in parallel was discussed in issues 8 of the 
trac-to-github repo  
(see this comment there 
).
 
To simplify our manual workflows and keep the redundant labels reliable, I 
implemented a bot to sync these labels with their corresponding GitHub 
states. Please take a look at PR #35172 
.

Best
Sebastian

-- 
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/9460dea8-4a34-4aca-a11e-b5dc0c635443n%40googlegroups.com.

[sage-devel] Warning: Migrated participants of a migrated Trac ticket are not notified

[seb....@gmail.com]

Hi everybody,

As we observed on  issue #17030 
  (see comments followin this 
one ): 
commenting on a migrated ticket does not notify the migrated participants. 
So, keep in mind that you have to mention them explicitly.

Sebastian

-- 
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/f654d758-418e-4313-b6c1-568e1bb7d414n%40googlegroups.com.

[sage-devel] Knot theory: Change PD-code convention

[seb....@gmail.com]

Hi everybody,

The PD (Planar Diagram) notation is one of the most important concepts to 
define a knot or link uniquely (besides the braid notation). Unfortunately 
our convention on how to read the four strands meeting at a crossing is 
opposite to the one used in most other places: We read them in clockwise 
direction whereas most others do it anti-clockwise.

I've started a discussion in issue #17030 
 (the ticket that introduced 
knot theory in Sage in 2014) to change our convention accordingly (starting 
from this comment 
).

If you have objections to this, please comment there!

Sebastian

-- 
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/f0af53f5-6b62-4af6-82fe-0e983d7145f3n%40googlegroups.com.

Re: [sage-devel] Re: Colours

[seb....@gmail.com]

FWIW: I've observed a similar behavior (see this post 
). I 
was using Firefox with a markdown plugin. In the preview, MD rendered 
correctly (I used quotes (">") and inline code ("`") tags). After posting, 
MD was removed and the quoted line appeared in red.


Nils Bruin schrieb am Samstag, 4. Februar 2023 um 01:32:48 UTC+1:

> On Friday, 3 February 2023 at 16:31:38 UTC-8 Nils Bruin wrote:
> On Friday, 3 February 2023 at 03:44:55 UTC-8 dim...@gmail.com wrote:
>
> I think this happens if you use Google's interface to Groups, rather 
> than an email client. 
>
> Nope , google groups interface formats quoted text with a line to the left 
> (as above). No colour introduced either. Perhaps there are some settings 
> that change how quoted text is configured, but there's definitely a setting 
> (and I would think the default) that typesets it as in this message.
>
> Oh, ouch. That is in the preview! when it's posted it indeed just displays 
> with a colour difference! This is an issue for googlegroups accessibility. 
>

-- 
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/aabe3760-6ed1-44ac-b9d5-d0f267104bc2n%40googlegroups.com.

Re: [sage-devel] Re: Please inspect: Migrated Trac tickets on our temporary GitHub server

[seb....@gmail.com]

I knew that argument. But isn't it much easier to select an entry from a 
list of almost 100 entries by typing two or three characters instead of 
scrolling through the list? If we were to change enhancement to enhancement 
/te (t for type to Trac) and needs work to needs work /snw (s for status), 
these could be easily selected as well. Here I assume that it is not a 
problem to change a predefined label.


Matthias Koeppe schrieb am Mittwoch, 25. Januar 2023 um 22:04:35 UTC+1:

> On Wednesday, January 25, 2023 at 12:55:59 PM UTC-8 seb@gmail.com 
> wrote:
>
> Why not do it completely without prefixes and use the /abc postfix to have 
> convienient access to all labels. For example algebra /ca in stead of c: 
> algebra, algebraic geometry /cag instead of c: algebraic geometry … 
> We are using the prefixes so that in the alphabetically sorted label list 
> in the user interface, there is a consecutive chunk of labels that 
> correspond to components. It's very untidy when the list of component 
> labels is interrupted by other labels such as "enhancement", "needs work" 
> etc.
>
>
>
>  
>

-- 
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/0b8732d1-9ca5-41f0-9eb5-910b6b80631fn%40googlegroups.com.

Re: [sage-devel] Re: Please inspect: Migrated Trac tickets on our temporary GitHub server

[seb....@gmail.com]

Sorry, Google killed the formatting of my Markdown plugin and I can't 
figure out how to edit the post any more. I hope you can read my preceding 
post! 

seb@gmail.com schrieb am Mittwoch, 25. Januar 2023 um 21:55:59 UTC+1:

> But why we insist to have the convenience that is absent for all other 
> labels? 
>
> How about doing it the other way round? Use it for the other labels too. 
> Why not do it completely without prefixes and use the /abc postfix to 
> have convienient access to all labels. For example algebra /ca in stead 
> of c: algebra, algebraic geometry /cag instead of c: algebraic geometry … 
> Typing ca will give you all component labels starting with a and cat 
> pulls algebraic topology to the first row. 
> ​
> Kwankyu Lee schrieb am Mittwoch, 25. Januar 2023 um 02:46:35 UTC+1:
>
>> I am not sure if the "/ 1", "/ 2", "/ 3", "/ 4", "/ 5" postfixes are 
>> really helpful. Note that
>>
>> (1) As Matthias noticed, the priority labels are sorted in the correct 
>> order without those prefixes. 
>> (2) The label text and the label color already indicate the priority.
>> (3) The numeral postfix is somewhat confusing since "5" may be 
>> interpreted as the highest priority and "1" lowest.
>>
>> Matthias pointed out that we can choose the priority label by one key 
>> stroke (for example, you can type "1" to get "p: blocker / 1"). But why we 
>> insist to have the convenience that is absent for all other labels? 
>>
>>

-- 
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/ac7fb506-1402-4b4d-a586-d459b4d02debn%40googlegroups.com.

Re: [sage-devel] Re: Please inspect: Migrated Trac tickets on our temporary GitHub server

[seb....@gmail.com]

 

But why we insist to have the convenience that is absent for all other 
labels? 

How about doing it the other way round? Use it for the other labels too. 
Why not do it completely without prefixes and use the /abc postfix to have 
convienient access to all labels. For example algebra /ca in stead of c: 
algebra, algebraic geometry /cag instead of c: algebraic geometry … Typing 
ca will give you all component labels starting with a and cat pulls algebraic 
topology to the first row. 
​
Kwankyu Lee schrieb am Mittwoch, 25. Januar 2023 um 02:46:35 UTC+1:

> I am not sure if the "/ 1", "/ 2", "/ 3", "/ 4", "/ 5" postfixes are 
> really helpful. Note that
>
> (1) As Matthias noticed, the priority labels are sorted in the correct 
> order without those prefixes. 
> (2) The label text and the label color already indicate the priority.
> (3) The numeral postfix is somewhat confusing since "5" may be interpreted 
> as the highest priority and "1" lowest.
>
> Matthias pointed out that we can choose the priority label by one key 
> stroke (for example, you can type "1" to get "p: blocker / 1"). But why we 
> insist to have the convenience that is absent for all other labels? 
>
>

-- 
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/6c6c50d9-ef0e-491d-b271-437a0aaeed97n%40googlegroups.com.

Re: [sage-devel] Re: Please inspect: Migrated Trac tickets on our temporary GitHub server

[seb....@gmail.com]

Since we can't be sure that all tickets have been converted correctly, I 
prefer to keep the link clickable for as long as possible! Furthermore, I 
think we should not erase the traces of the migration.

dim...@gmail.com schrieb am Mittwoch, 18. Januar 2023 um 09:45:49 UTC+1:

> On Wed, Jan 18, 2023 at 8:16 AM Kwankyu Lee  wrote:
> >
> > In the issue description, I see "Issue created by migration from 
> https://trac.sagemath.org/ticket/...";. Would we remove this before 
> migration? Perhaps we should because the link will be defunct eventually.
>
> The plan is to have the trac website in a read-only form, perhaps on
> archive,org,
> or somewhere else. So I think it's OK to keep these - perhaps not 
> clickable.
> Anyhow, this can be edited later using a GitHub API.
>
> >
> >
> >
> >
> > --
> > 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/9b560c7a-3f2f-4447-b2f5-ff580bb8ff09n%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/8c18155a-2cd9-41ab-9e73-cc3f276e5497n%40googlegroups.com.

[sage-devel] Re: Help wanted: Trac wiki migration, improve markup conversion code

[seb....@gmail.com]

I opened issue #18 <https://github.com/sagemath/trac-to-github/issues/18> 
to collect the tasks related to this thread. I asked a few questions there. 
Please take a look.
​
Matthias Koeppe schrieb am Mittwoch, 16. November 2022 um 20:48:02 UTC+1:

> Thank you! Merged and updated https://github.com/sagemath/trac_to_gh/wiki
>
> Some more issues that I have spotted:
>
> Sections with fragment names
> e.g. `== Legacy sage-trac Account Request == #legacy-account-request`
>
> https://github.com/sagemath/trac_to_gh/wiki#account-names-mapped-to-real-names
>
> Various bad links
> e.g. `PageOutline` and `
> https://groups.google.com/forum/#!forum/sage-packaging` 
> <https://groups.google.com/forum/#!forum/sage-packaging>
> on https://github.com/sagemath/trac_to_gh/wiki/Distribution
>
> Various missing links
> e.g. [wiki:symbolics/maxima] and [
> https://en.wikipedia.org/wiki/Symbolic_computation]
> on https://github.com/sagemath/trac_to_gh/wiki/symbolics
>
> On Wednesday, November 16, 2022 at 9:55:38 AM UTC-8 seb@gmail.com 
> wrote:
>
>> For now I would create links with URLs of Trac tickets.
>>
>> I’ve opened PR 15 <https://github.com/sagemath/trac-to-github/pull/15> 
>> for this.
>>
>> What else is of importance? The headings in the tables, I guess.
>> ​
>> Matthias Koeppe schrieb am Dienstag, 15. November 2022 um 20:15:55 UTC+1:
>>
>>> For now I would create links with URLs of Trac tickets.
>>> They can be easily rewritten by a script as soon as we have migrated 
>>> Trac tickets to GH Issues.
>>>
>>> On Tuesday, November 15, 2022 at 10:53:13 AM UTC-8 kcrisman wrote:
>>>
>>>> Question (which I am unfortunately unable to assess): Is it possible 
>>>> that Trac ticket link of the form #xyzwv could automatically become links 
>>>> to the same GH issues once all migration is complete?  I'm thinking of 
>>>> pages like https://github.com/sagemath/trac_to_gh/wiki/symbolics - the 
>>>> Trac version of this was quite useful.
>>>>  
>>>> On Monday, November 14, 2022 at 3:55:33 PM UTC-5 Matthias Koeppe wrote:
>>>>
>>>>> As the next step in our migration to GitHub, let's migrate the Trac 
>>>>> wiki.
>>>>>
>>>>> I have done a preliminary conversion of the using our conversion 
>>>>> script (https://github.com/sagemath/trac-to-github.git) to markdown 
>>>>> files, now at https://github.com/sagemath/trac_to_gh/wiki
>>>>>
>>>>>

-- 
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/1ec18a14-3375-4846-b70b-57cfb3b3e14bn%40googlegroups.com.

[sage-devel] Re: Help wanted: Trac wiki migration, improve markup conversion code

[seb....@gmail.com]

What else is of importance? The headings in the tables, I guess.

This PR 16 <https://github.com/sagemath/trac-to-github/pull/16/>, now.
​
seb@gmail.com schrieb am Mittwoch, 16. November 2022 um 18:55:38 UTC+1:

> For now I would create links with URLs of Trac tickets.
>
> I’ve opened PR 15 <https://github.com/sagemath/trac-to-github/pull/15> 
> for this.
>
> What else is of importance? The headings in the tables, I guess.
> ​
> Matthias Koeppe schrieb am Dienstag, 15. November 2022 um 20:15:55 UTC+1:
>
>> For now I would create links with URLs of Trac tickets.
>> They can be easily rewritten by a script as soon as we have migrated Trac 
>> tickets to GH Issues.
>>
>> On Tuesday, November 15, 2022 at 10:53:13 AM UTC-8 kcrisman wrote:
>>
>>> Question (which I am unfortunately unable to assess): Is it possible 
>>> that Trac ticket link of the form #xyzwv could automatically become links 
>>> to the same GH issues once all migration is complete?  I'm thinking of 
>>> pages like https://github.com/sagemath/trac_to_gh/wiki/symbolics - the 
>>> Trac version of this was quite useful.
>>>  
>>> On Monday, November 14, 2022 at 3:55:33 PM UTC-5 Matthias Koeppe wrote:
>>>
>>>> As the next step in our migration to GitHub, let's migrate the Trac 
>>>> wiki.
>>>>
>>>> I have done a preliminary conversion of the using our conversion script 
>>>> (https://github.com/sagemath/trac-to-github.git) to markdown files, 
>>>> now at https://github.com/sagemath/trac_to_gh/wiki
>>>>
>>>>

-- 
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/60ef1592-3b63-459a-93aa-854f10b1n%40googlegroups.com.

[sage-devel] Re: Help wanted: Trac wiki migration, improve markup conversion code

[seb....@gmail.com]

For now I would create links with URLs of Trac tickets.

I’ve opened PR 15  for 
this.

What else is of importance? The headings in the tables, I guess.
​
Matthias Koeppe schrieb am Dienstag, 15. November 2022 um 20:15:55 UTC+1:

> For now I would create links with URLs of Trac tickets.
> They can be easily rewritten by a script as soon as we have migrated Trac 
> tickets to GH Issues.
>
> On Tuesday, November 15, 2022 at 10:53:13 AM UTC-8 kcrisman wrote:
>
>> Question (which I am unfortunately unable to assess): Is it possible that 
>> Trac ticket link of the form #xyzwv could automatically become links to the 
>> same GH issues once all migration is complete?  I'm thinking of pages like 
>> https://github.com/sagemath/trac_to_gh/wiki/symbolics - the Trac version 
>> of this was quite useful.
>>  
>> On Monday, November 14, 2022 at 3:55:33 PM UTC-5 Matthias Koeppe wrote:
>>
>>> As the next step in our migration to GitHub, let's migrate the Trac wiki.
>>>
>>> I have done a preliminary conversion of the using our conversion script (
>>> https://github.com/sagemath/trac-to-github.git) to markdown files, now 
>>> at https://github.com/sagemath/trac_to_gh/wiki
>>>
>>>

-- 
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/6c4233a9-e801-4a5d-a1b0-408bf5788454n%40googlegroups.com.

[sage-devel] Re: Help wanted: Issue and PR templates, replacement for ticket dependencies

[seb....@gmail.com]

More generally, I see little benefit in trying to stay close to the format 
of trac tickets.

I didn’t think of having this as the default template. Just an optional 
template for former Trac users who are less familiar with GitHub (like me). 
But as I’ve now seen, templates and issue forms aren’t the right tools for 
an interface, and it’s probably harder to do than I expected. Perhaps it 
would be sufficient to have a reference to the migration documentation 
 in 
all the templates we offer, at least for the initial period after the 
migration has taken place.
​
Marc Mezzarobba schrieb am Mittwoch, 19. Oktober 2022 um 10:35:55 UTC+2:

> John H Palmieri wrote:
> > I like the idea of mimicking the trac setup, but moving away from trac
> > also lets us reconsider parts of the trac interface. I personally do
> > not find the "Priority" label very helpful, other than whether it's a
> > blocker or not. What do others think?
>
> I agree about the Priority field. I also find the Type and Component
> fields useless most of the time. (Regarding Component, many of the
> possible values don't map well IMO to either actual code components or
> developer interests, but a few do. In any case, I don't think it should
> be mandatory.)
>
> More generally, I see little benefit in trying to stay close to the
> format of trac tickets. I would just start with a few labels for ticket
> properties that are widely used now (bug, blocker, maybe a couple of
> well-defined components...), allow people to create labels and projects
> as they see fit, and let new conventions emerge.
>
> -- 
> Marc Mezzarobba
>
>

-- 
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/51f599cd-9554-4c48-888c-6e648e8e53bcn%40googlegroups.com.

[sage-devel] Re: Help wanted: Issue and PR templates, replacement for ticket dependencies

[seb....@gmail.com]

There are two essential disadvantages of the issue form:

1. It is not available for PR.
2. The given structure is completely flattened after the issue has been 
created. In particular, the entries of the dropdown menus of the issue 
header are not visible (i.e. dropdown boxes are flattened to the selected 
entry) .

An advantage is that the issue is not created until all checkboxes are set. 
So this can be used to make things mandatory. This doesn't seem to be 
possible with the template.


tobias...@gmail.com schrieb am Montag, 17. Oktober 2022 um 21:07:12 UTC+2:

> You can have advanced more advanced controls like checkboxes or 
> dropdownboxes in issue forms, see 
> https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema#dropdown.
>  
> Some of this is used in 
> https://github.com/sagemath/sage-gh-templates-sandbox/pull/1.
>
> On Monday, 17 October 2022 at 19:50:45 UTC+2 seb@gmail.com wrote:
>
>> I think there are two steps to be taken. The first step is to define a 
>> suitable template to collect all the important information in the header of 
>> issues and PRs that we are used to from the Trac ticket box.
>>
>> In terms of dependencies between PRs, this will map what we are used to. 
>> The second step according to discussion 4477 
>> <https://github.com/orgs/community/discussions/4477> will go beyond 
>> that. So this has a lower priority. But it will be nice to have!
>>
>> As for the first step, I would suggest having templates that mimic the 
>> Trac ticket box for example:
>>
>> $ cat .github/ISSUE_TEMPLATE/trac_ticket_like_issue.md
>> ---
>> name: Issue according to Trac ticket
>> about: This template provides a similar structure to a Trac ticket
>> title: "[Short Description] "
>> labels: 'p:major'
>> milestone: 'sage-9.8'
>> assignees: ''
>>
>> ---
>>
>> # Checklist for creating a Trac ticket-like issue
>>
>> - [ ] I have read 
>> [README.md](https://github.com/sagemath/sage/blob/develop/README.md)
>> - [ ] I have read [the Troubleshooting section in the Installation 
>> Guide](https://doc.sagemath.org/html/en/installation/troubles.html)
>> - [ ] I have checked that this will not be a duplicate
>> - [ ] I have chosen a label from the Type 
>> listt:bugt:enhancementt:task
>> - [ ] I have chosen a label from the Priority 
>> listp:blockerp:criticalp:majorp:minorp:trivial
>> - [ ] I have chosen a label from the Component 
>> listc:algebrac:algebraic 
>> geometryc:...
>>
>> # Information that used to be in the Trac ticket box
>>
>> |||||
>> |-|-|-|-|
>> |Authors||Reviewers||
>> |Keywords||Report upstream||
>> |Dependencies||Stopgaps||
>>
>> # Description of the issue
>>
>> This would also help with the change of habits. But it seems that this 
>> cannot be done only through appropriate templates. As far as I’ve seen, 
>> there’s no way to have radio buttons or select lists with GitHub markdown, 
>> even with plain HTML. Therefore, we would also need to implement 
>> corresponding GitHub actions (see also my comment on issue 8 
>> <https://github.com/sagemath/trac-to-github/issues/8> in the trac-to-github 
>> repo <https://github.com/sagemath/trac-to-github/>). These would be 
>> needed to synchronize between corresponding Trac and GitHub features, too.
>>
>> If there is interest to have such a template I can volunteer to produce a 
>> first draft (but maybe this will take a while since I have only short 
>> time-slots and I’m inexperienced with these GitHub tools).
>> ​
>> Matthias Koeppe schrieb am Montag, 10. Oktober 2022 um 20:42:28 UTC+2:
>>
>>> As discussed previously, Issue and PR templates on GitHub can provide a 
>>> replacement for the Trac ticket box. See 
>>> ​https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository
>>>  
>>> <https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository>
>>>
>>> https://github.com/sagemath/sage-gh-templates-sandbox is open for 
>>> trying out possible designs for these templates. A first draft of one 
>>> template:
>>> ​https://github.com/sagemath/sage-gh-templates-sandbox/issues/new/choose 
>>> <https://github.com/sagemath/sage-gh-templat

[sage-devel] Re: Help wanted: Issue and PR templates, replacement for ticket dependencies

[seb....@gmail.com]

Probably better to use labels, since we see issues change from blocker to 
not and then back again, so having different templates would be cumbersome.

I agree! In general the predefined structure of templates is not guaranteed 
to be preserved through the live of an issue / PR as we are used to with 
the Trac ticket box. Everyone with write access can destroy it. Surely this 
will demand a higher level of discipline among developers.

A broader question is, which parts of the trac interface do we want to 
keep, and which parts can we dispense with? Also, where is the right place 
to have this discussion?

I don’t know. Maybe a Trac ticket, since this must be clarified before we 
migrate?
​
John H Palmieri schrieb am Montag, 17. Oktober 2022 um 20:59:37 UTC+2:

> I like the idea of mimicking the trac setup, but moving away from trac 
> also lets us reconsider parts of the trac interface. I personally do not 
> find the "Priority" label very helpful, other than whether it's a blocker 
> or not. What do others think? We could just ask people to label "Blocker" 
> if necessary, or I suppose have one template for a blocker, one template 
> for everything else. (Probably better to use labels, since we see issues 
> change from blocker to not and then back again, so having different 
> templates would be cumbersome.) 
>
> A broader question is, which parts of the trac interface do we want to 
> keep, and which parts can we dispense with? Also, where is the right place 
> to have this discussion?
>
> On Monday, October 17, 2022 at 10:50:45 AM UTC-7 seb@gmail.com wrote:
>
>> I think there are two steps to be taken. The first step is to define a 
>> suitable template to collect all the important information in the header of 
>> issues and PRs that we are used to from the Trac ticket box.
>>
>> In terms of dependencies between PRs, this will map what we are used to. 
>> The second step according to discussion 4477 
>> <https://github.com/orgs/community/discussions/4477> will go beyond 
>> that. So this has a lower priority. But it will be nice to have!
>>
>> As for the first step, I would suggest having templates that mimic the 
>> Trac ticket box for example:
>>
>> $ cat .github/ISSUE_TEMPLATE/trac_ticket_like_issue.md
>> ---
>> name: Issue according to Trac ticket
>> about: This template provides a similar structure to a Trac ticket
>> title: "[Short Description] "
>> labels: 'p:major'
>> milestone: 'sage-9.8'
>> assignees: ''
>>
>> ---
>>
>> # Checklist for creating a Trac ticket-like issue
>>
>> - [ ] I have read 
>> [README.md](https://github.com/sagemath/sage/blob/develop/README.md)
>> - [ ] I have read [the Troubleshooting section in the Installation 
>> Guide](https://doc.sagemath.org/html/en/installation/troubles.html)
>> - [ ] I have checked that this will not be a duplicate
>> - [ ] I have chosen a label from the Type 
>> listt:bugt:enhancementt:task
>> - [ ] I have chosen a label from the Priority 
>> listp:blockerp:criticalp:majorp:minorp:trivial
>> - [ ] I have chosen a label from the Component 
>> listc:algebrac:algebraic 
>> geometryc:...
>>
>> # Information that used to be in the Trac ticket box
>>
>> |||||
>> |-|-|-|-|
>> |Authors||Reviewers||
>> |Keywords||Report upstream||
>> |Dependencies||Stopgaps||
>>
>> # Description of the issue
>>
>> This would also help with the change of habits. But it seems that this 
>> cannot be done only through appropriate templates. As far as I’ve seen, 
>> there’s no way to have radio buttons or select lists with GitHub markdown, 
>> even with plain HTML. Therefore, we would also need to implement 
>> corresponding GitHub actions (see also my comment on issue 8 
>> <https://github.com/sagemath/trac-to-github/issues/8> in the trac-to-github 
>> repo <https://github.com/sagemath/trac-to-github/>). These would be 
>> needed to synchronize between corresponding Trac and GitHub features, too.
>>
>> If there is interest to have such a template I can volunteer to produce a 
>> first draft (but maybe this will take a while since I have only short 
>> time-slots and I’m inexperienced with these GitHub tools).
>> ​
>> Matthias Koeppe schrieb am Montag, 10. Oktober 2022 um 20:42:28 UTC+2:
>>
>>> As discussed previously, Issue and PR templates on GitHub can provide a 
>>> replacement for the Trac ticket box. See 
>>> ​https://docs.github.com/en/

[sage-devel] Re: Help wanted: Issue and PR templates, replacement for ticket dependencies

[seb....@gmail.com]

I think there are two steps to be taken. The first step is to define a 
suitable template to collect all the important information in the header of 
issues and PRs that we are used to from the Trac ticket box.

In terms of dependencies between PRs, this will map what we are used to. 
The second step according to discussion 4477 
 will go beyond that. 
So this has a lower priority. But it will be nice to have!

As for the first step, I would suggest having templates that mimic the Trac 
ticket box for example:

$ cat .github/ISSUE_TEMPLATE/trac_ticket_like_issue.md
---
name: Issue according to Trac ticket
about: This template provides a similar structure to a Trac ticket
title: "[Short Description] "
labels: 'p:major'
milestone: 'sage-9.8'
assignees: ''

---

# Checklist for creating a Trac ticket-like issue

- [ ] I have read 
[README.md](https://github.com/sagemath/sage/blob/develop/README.md)
- [ ] I have read [the Troubleshooting section in the Installation 
Guide](https://doc.sagemath.org/html/en/installation/troubles.html)
- [ ] I have checked that this will not be a duplicate
- [ ] I have chosen a label from the Type 
listt:bugt:enhancementt:task
- [ ] I have chosen a label from the Priority 
listp:blockerp:criticalp:majorp:minorp:trivial
- [ ] I have chosen a label from the Component 
listc:algebrac:algebraic 
geometryc:...

# Information that used to be in the Trac ticket box

|||||
|-|-|-|-|
|Authors||Reviewers||
|Keywords||Report upstream||
|Dependencies||Stopgaps||

# Description of the issue

This would also help with the change of habits. But it seems that this 
cannot be done only through appropriate templates. As far as I’ve seen, 
there’s no way to have radio buttons or select lists with GitHub markdown, 
even with plain HTML. Therefore, we would also need to implement 
corresponding GitHub actions (see also my comment on issue 8 
 in the trac-to-github 
repo ). These would be needed 
to synchronize between corresponding Trac and GitHub features, too.

If there is interest to have such a template I can volunteer to produce a 
first draft (but maybe this will take a while since I have only short 
time-slots and I’m inexperienced with these GitHub tools).
​
Matthias Koeppe schrieb am Montag, 10. Oktober 2022 um 20:42:28 UTC+2:

> As discussed previously, Issue and PR templates on GitHub can provide a 
> replacement for the Trac ticket box. See 
> ​https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository
>  
> 
>
> https://github.com/sagemath/sage-gh-templates-sandbox is open for trying 
> out possible designs for these templates. A first draft of one template:
> ​https://github.com/sagemath/sage-gh-templates-sandbox/issues/new/choose 
> 
>
>
> Related: Help is needed with choosing a good replacement for our Trac 
> ticket dependencies. As suggested in 
> ​https://github.com/sagemath/publications/pull/142#issuecomment-1259001501 
> 
>  and ​https://groups.google.com/g/sage-devel/c/hX6ojxlNwOU/m/dup_Ywu1BQAJ 
> , we 
> should add to ​the transition guide 
> 
>  how 
> to model Trac's ticket dependencies in GitHub PRs. See 
> ​https://github.com/orgs/community/discussions/4477 
>  for solutions.
>
>
> This is part of https://trac.sagemath.org/ticket/30363
>

-- 
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/c6c3a88c-f456-45e5-a51d-e5cc55c6a023n%40googlegroups.com.

Re: [sage-devel] Re: Democratic issue: rushing decisions

[seb....@gmail.com]

If a few people felt the need to delay, that should have an effect.

Surely! But indeed there was an (maybe to small) effect in the migration 
vote. On September 14, I suggested a compromise 
 
between David’s first proposal 
 and 
Thierry’s intervention for delay 
. This 
has been taken into account in the final proposal 
.
​
John H Palmieri schrieb am Freitag, 7. Oktober 2022 um 18:55:09 UTC+2:

> On Friday, October 7, 2022 at 9:48:29 AM UTC-7 tobias...@gmail.com wrote:
>
>> I just had another look at the voting thread, where most votes were 
>> voiced in the first two days, and the almost-slient discussion thread, 
>> where mostly a few practical aspects of the migrations were discussed. From 
>> this, I don't get the impression that the most voters felt they needed more 
>> time to think or discuss their decision.
>>
>
> Discussions about the timing of the vote were mainly in the thread 
> "incremental migration to github?", not the discussion thread or the vote 
> thread.Also, I'm not sure it matters what "most voters" felt. If a few 
> people felt the need to delay, that should have an effect.
>
>  
>
>>
>> In general, I would keep the voting system simple. The migration to 
>> github was one particular vote, but for example the voting on the doc 
>> styles was held without much of a prior discussion and on a shorter 
>> deadline.
>>
>> So maybe something simple as the following?
>> "Small votes:" Have to have a github issue that is at least one week old, 
>> don't require a discussion on the mailing list and the voting period cannot 
>> be shorter than 4 days.
>> "Big votes": Require a discussion thread on the mailing list that is at 
>> least one week old and the voting period cannot be shorter than 1.5 weeks.
>> Upon the public request of a single member of the mailing list, every 
>> "small vote" can be upgraded to a "big vote". In this case, all previously 
>> handed-in votes are invalid and a discussion thread has to be opened.
>>
>> On Friday, 7 October 2022 at 17:43:02 UTC+2 John H Palmieri wrote:
>>
>>> I apologize for being indirect. I was responding to Dima's sentence, 
>>> "... the delay was requested by an individual ..." which implies that there 
>>> was just one person requesting the delay. I was pointing out, apparently 
>>> too indirectly, that more than one person had requested a delay, and 
>>> perhaps not everyone who requested a delay was guilty, in Dima's view, of 
>>> some transgression.
>>>
>>> In short: Dima, cut it out with the straw men ("straw man: an 
>>> intentionally misrepresented proposition that is set up because it is 
>>> easier to defeat than an opponent's real argument").
>>>
>>>
>>> On Friday, October 7, 2022 at 3:45:27 AM UTC-7 dim...@gmail.com wrote:
>>>
 On Fri, Oct 7, 2022 at 12:19 AM Kwankyu Lee  wrote: 
 > 
 > 
 > 
 > On Friday, October 7, 2022 at 7:05:38 AM UTC+9 John H Palmieri wrote: 
 >> 
 >> Dima, presumably you're not talking about me, although I proposed 
 that "we start a vote around October 1". 
 > 
 > 
 > I guess he means: https://trac.sagemath.org/ticket/33725#comment:26 

 yes, that's exactly what I meant. 

 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+...@googlegroups.com. 
 > To view this discussion on the web visit 
 https://groups.google.com/d/msgid/sage-devel/be5e2daa-6e2d-4437-bc3a-a8bf38f5a5c6n%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/31a2244f-31a7-4f6b-82fc-b4da8b08861en%40googlegroups.com.

[sage-devel] Sage seems to be broken on Gitpod workspaces

[seb....@gmail.com]

Hi,

at least since 9.8.beta1 I get:

(base) gitpod@sagemath-sagetracmirror-bkjzz4skuj7:/workspace/sagetrac-mirror$ 
sage
bash: sage: command not found
(base) gitpod@sagemath-sagetracmirror-bkjzz4skuj7:/workspace/sagetrac-mirror$ 
./sage
Traceback (most recent call last):
  File "/workspace/sagetrac-mirror/src/bin/sage-ipython", line 9, in 
from sage.misc.banner import banner
ModuleNotFoundError: No module named 'sage'
(base) gitpod@sagemath-sagetracmirror-bkjzz4skuj7:/workspace/sagetrac-mirror$ 
echo $PATH
/opt/conda/bin:/opt/conda/condabin:/ide/bin/remote-cli:/opt/conda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/workspace/sagetrac-mirror/venv/bin
(base) gitpod@sagemath-sagetracmirror-bkjzz4skuj7:/workspace/sagetrac-mirror$ 
ls -ltr venv
ls: cannot access 'venv': No such file or directory

In this example I invoked Gitpod via the badged on ticket #33969 

 
after rebasing to the current beta. On a pinned workspace under 9.7.beat8 
it is still working:

(/workspace/sagetrac-mirror/venv) 
gitpod@sagemath-sagetracmirror-umr7r154gqk:/workspace/sagetrac-mirror$ sage
┌┐
│ SageMath version 9.7.beta8, Release Date: 2022-08-07   │
│ Using Python 3.10.5. Type "help()" for help.   │
└┘
┏┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗┛
sage: quit
(/workspace/sagetrac-mirror/venv) 
gitpod@sagemath-sagetracmirror-umr7r154gqk:/workspace/sagetrac-mirror$ which 
sage
/workspace/sagetrac-mirror/venv/bin/sage

(/workspace/sagetrac-mirror/venv) 
gitpod@sagemath-sagetracmirror-umr7r154gqk:/workspace/sagetrac-mirror$ echo 
$PATH
/workspace/sagetrac-mirror/venv/bin:/opt/conda/condabin:/ide/bin/remote-cli:/opt/conda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/workspace/sagetrac-mirror/venv/bin

​

-- 
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/09ec84b4-8c14-42c6-aaa4-01a5ace5ed53n%40googlegroups.com.

Re: [sage-devel] DISCUSS: move Sage development to Github

[seb....@gmail.com]

Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46 UTC+2:

On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 wrote:
>
>> Is it possible to choose the issue numbers in GH when making a migration? 
>> Then, setting a redirect of the form "
>> https://trac.sagemath.org/ticket/$TICKET_NUMBER -> 
>> https://github.com/sagemath/sage/issues/$TICKET_NUMBER"; will make the 
>> lion's share of the links still relevant.
>>
>
> Yes, to map it like this is the plan.
>  
>
>> This does not preserve fragments like "#comment:7", which is useful in 
>> long ticket discussions.
>>
>
> Thanks, I've opened https://github.com/sagemath/trac-to-github/issues/7 
> for this.
>
Don’t we need an issue for the first point, as well? The example #26 
 corresponds to #34110 
 which is not easy to recover from 
the migrated information.

Furthermore, it isn’t still clear to me how dependencies between PRs will 
be visible (like in the Trac dependencies field). In the above example you 
have to recover this from the history of commit messages (which may not be 
clear enough in general). Shouldn’t the migration put something into the 
header fields milestone, assignees, …, as well (if possible)? How will 
authors and reviewers be visible?
​

-- 
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/bb6690bd-809b-41d8-a0ed-8b45f6b4def9n%40googlegroups.com.

[sage-devel] Re: VOTE: move Sage development to Github

[seb....@gmail.com]

 +1 for Github  (personally I still prefer Trac, but the bus factor 
argument and recruitment of new contributors are more important)

emanuel.c...@gmail.com schrieb am Freitag, 23. September 2022 um 08:37:26 
UTC+2:

> +1 for Github
>
> Also wishing for contingency plan for re-migrating to self-hosted Gitlab. 
>
> Le mercredi 21 septembre 2022 à 19:23:36 UTC+2, David Roe a écrit :
>
>> Dear Sage developers,
>> Following extensive discussion, both recently 
>>  
>> (prompted 
>> by issues upgrading the trac server) and over 
>>  the 
>>  
>> last 
>>  
>> decade 
>> , 
>> we are calling a vote on switching Sage development from Trac 
>>  to Github .  We've 
>> created a summary of the pros and cons of each system 
>> , a 
>> description 
>> of the development model to be used on github 
>> , 
>> and a trac ticket  for 
>> coordinating work on the transition.  More work will need to be done to 
>> carry out the actual transition once voting is complete.
>>
>> The voting will last until noon Eastern time (16:00 UTC) on Wednesday, 
>> October 5.  Please use this thread only for sending votes, to make it 
>> easier to count them afterward; there is a parallel thread where you can 
>> make arguments in favor of either system.
>>
>> Finally, I will close with a plea to be involved in this vote and 
>> discussion even if you are not a core Sage developer.  By definition, core 
>> Sage developers have become comfortable with trac, and I think that one of 
>> the major arguments in favor of github is that it will help bring in new 
>> contributors who are not familiar with Sage's development workfow 
>> .  Anyone who has 
>> ever contributed to the Sage code base or who maintains a Sage user package 
>> is welcome to vote.
>> David
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d9ab2e92-c067-46c8-bc27-04cc72c64febn%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[seb....@gmail.com]

Matthias Koeppe schrieb am Donnerstag, 15. September 2022 um 21:22:25 UTC+2:

> On Thursday, September 15, 2022 at 2:09:23 AM UTC-7 Samuel Lelievre wrote:
>
>> c. Several people refuse to open a GitHub account 
>
>  
> I don't know anyone who does. I think they should speak up for themselves 
> (unless they also refuse to participate in this list hosted on Google) so 
> we can understand what their concern is.
>
>  
>

Potentially, I'm that kind of person and I think it is very important that 
Samuel posted these points!

About ten years before Google was on Earth someone put a poster on our 
corridor of the University building: *Microsoft free area*. We all were 
proud about that. But at that point nobody knew what should come later on.

In the 80ties Germany planned a nationwide census to happen once in a 
decade. I joined the resistance against it. From today's point of view this 
is absolutely ridiculous. Each day people sell much more sensitive data to 
many powerful companies and it is much less clear how they deal with your 
data.

It has become really hard to refuse all the things you would like to and 
you are forced to make exceptions. Until Corona I refused to use a 
smartphone. Now I use my employer's iPhone. But I use it less than 2 
minutes a day (most of that 2FA and just WiFi).

The principal question is: What is worth making an exception? I think Sage 
is worth it!

  

-- 
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/f1ba1b29-6fda-4873-8e44-c0a4b117e52an%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[seb....@gmail.com]

Thank you both!

Matthias Koeppe schrieb am Donnerstag, 15. September 2022 um 18:17:11 UTC+2:

> On Wednesday, September 14, 2022 at 11:40:12 PM UTC-7 seb....@gmail.com 
> wrote:
>
>> What is the proposed workflow to merge the develop branch after a new 
>> release into PR (or other) branches of your fork (i.e re-basing)? Obviously 
>> this is possible by pushing on sync in the web interface or typing gh 
>> repo sync USERNAME/sage -b branch in the command line. But how do you 
>> resolve conflicts?
>>
> Like Dima explained, all of the PR syncing is just additional convenience. 
> You can continue to just do all merging on your computer using the very 
> same git commands and just push the updated branch to your repo. It will 
> then be automatically reflected in the PR.
>  
>
>> If a PR is linked to the Issue, you can alternatively comment on the PR.
>>
>> It sounds like wasting time by searching for comments. Can’t we define a 
>> preference here? This seems to be a part of the decentralized structure 
>> that Travis is criticizing.
>>
> In actual practice, this is a non-problem, it is obvious where a comment 
> should go. 
> And in fact, also on Trac we often have overlapping discussions in related 
> tickets, and Sage developers have been able to navigate this quite well.
> But yes, we can provide explicit guidance to Sage developers. I've added a 
> few bits to 
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b in 
> this direction. Help is welcome in expanding 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/97302f85-b937-4859-815d-85092eb3596fn%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[seb....@gmail.com]

What is the proposed workflow to merge the develop branch after a new 
release into PR (or other) branches of your fork (i.e re-basing)? Obviously 
this is possible by pushing on sync in the web interface or typing gh repo 
sync USERNAME/sage -b branch in the command line. But how do you resolve 
conflicts?

BTW: I’m not sure I like this!

If a PR is linked to the Issue, you can alternatively comment on the PR.

It sounds like wasting time by searching for comments. Can’t we define a 
preference here? This seems to be a part of the decentralized structure 
that Travis is criticizing.
​
Matthias Koeppe schrieb am Mittwoch, 14. September 2022 um 23:19:28 UTC+2:

> I think for now we only need to describe the process up to the point of 
> "positive review".
> The discussion on how to do release management etc. is best held when 
> Volker finds the time to join the discussion on these things.
>
> On Wednesday, September 14, 2022 at 1:58:40 AM UTC-7 tobias...@gmail.com 
> wrote:
>
>> I think we need also another branch "merge-queue" which serves as the 
>> target for pull requests, with branch protection rules linear history, 
>> require positive review and checks.
>>
>> Also "Release Manager @vbraun merges positively reviewed tickets into his 
>> branch https://github.com/vbraun/sage"; should then be replaced by  
>> "Release Manager @vbraun merges positively reviewed tickets into the branch 
>> merge-queue". You cannot really "merge" pull requests against one repo into 
>> another one. 
>>
>> Moreover, I propose to realize "To make a beta or stable release, Release 
>> Manager merges (fast-forward) his branch into the develop branch and 
>> creates a tag" by a pull-request from "merge-queue" into "develop". This PR 
>> could then trigger the corresponding github action checks that should pass 
>> before a beta is released.  
>>
>> On Wednesday, 14 September 2022 at 07:50:48 UTC+2 Matthias Koeppe wrote:
>>
>>> On Tuesday, September 13, 2022 at 10:26:04 PM UTC-7 David Roe wrote:
>>>
 My understanding from the 
 allowing-changes-to-a-pull-request-branch-created-from-a-fork 
 documentation 
 
  is 
 that only users who have push permission on the repository will be able to 
 make edits to a pull request.  I think the consequence is that we want 
 active Sage developers to have Write access 
 
  
 to the repository, and then use branch protection rules 
 
  
 on develop and master.

>
>
>>> Yes, please take a look at 
>>> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-permissions-and-protections,
>>>  
>>> where I have started to write something like 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/ae0f1f0f-f68a-4169-8c5b-6b66a2937fc9n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[seb....@gmail.com]

David Roe schrieb am Mittwoch, 14. September 2022 um 07:39:26 UTC+2:

> On Tue, Sep 13, 2022 at 6:36 PM Dima Pasechnik  wrote:
>
>>
>>
>>
>>
>>
>>
>> On Tue, 13 Sep 2022, 23:03 Matthias Koeppe,  wrote:
>>
>>> On Tuesday, September 13, 2022 at 3:01:14 PM UTC-7 Thierry 
>>> (sage-googlesucks@xxx) wrote:
>>>
 Also, several people have already explicitely requested for a break (if 
 not a truce, given the level of agressivity).
>>>
>>>
>>> Excuse me, Thierry, your accusations about others being aggressive & 
>>> likening anything here to war is highly inappropriate.
>>>
>>
>> I repeat: we need no formal voting on this issue whatsoever - because 
>> trac is a long-standing liability, i.e. a bug that must be fixed, and we 
>> don't do voting on whether a bug is to be fixed, we go and fix it.
>> No, no truce, no quarter to bugs, sorry.
>>
>
> I disagree on whether we need a vote, obviously.  I think it's very 
> important for the whole community to be involved in discussing and agreeing 
> to a change as major as switching from trac to git**b.  My hope (and 
> expectation) is that the benefits of the switch will be sufficiently 
> apparent that we'll get buy-in from a solid majority of developers.  And 
> the giving time for that discussion and making an effort to convince people 
> is likely to improve our eventual setup, to the benefit of Sage.
>
> That being said, I don't think we should wait a month, as Thierry has 
> suggested.  I'm sympathetic to not having time to contribute to the switch 
> right now, which is why I've proposed a summary of pros and cons to be 
> included in the voting email.  Thierry, if you have more time in a couple 
> months, I'm sure that there will still be infrastructure improvements to be 
> made.
>

Can we find a compromise in the middle, for example 2 weeks after 
announcement? BTW: Is there a way to use the notification email addresses 
of Track to broadcast the announcement?

 

>
> As far as *my* mental health is concerned, I swear I will not touch the 
>> Sage project infrastructure any more -- unless we proceed with retiring 
>> trac.
>>
>
> That sounds very fair to me.  We all appreciate everything you've done on 
> the project's infrastructure, on top of the very visible way you help 
> people 
>

I would have no problem to count the votes of those who carry the burden of 
maintaining the Trac infrastructure with a higher weight.
 

> with build and support questions.  And for my part, I'm going to work with 
> you to try to make sure we do retire trac soon.
> David
>  
>
>>
>>
>>>
>>>
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "sage-devel" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to sage-devel+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/aaf7b1d7-747d-4318-974b-c8ea9e150d42n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/CAAWYfq1-xuF1JYtWV09hceaeSG%3Djvqs%2B_f%3Dti%2BQ%3D-z09T-6qkQ%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/0e81cdb1-e848-43a5-bf1c-dd783459abd9n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[seb....@gmail.com]

Thanks, this is already in a pretty nice shape! I’ve extended some points a 
bit. 

I think an explicit description of what will replace the states of a ticket 
(for example positive review) is still missing.

In my opinion, we can also directly drop the develop branch and move to the 
master/main-branch only model. But that’s slightly orthogonal to the 
migration to Github. 

I would rather put such suggestions explaining what can be done after the 
migration is finished into a separate MD-File.
​
tobias...@gmail.com schrieb am Sonntag, 11. September 2022 um 09:17:24 
UTC+2:

> On Saturday, 10 September 2022 at 21:32:50 UTC+2 Matthias Koeppe wrote:
>
>> On Saturday, September 10, 2022 at 8:12:48 AM UTC-7 Matthias Koeppe wrote:
>>
>>> I've added a draft of a proposed workflow on GitHub with the idea to 
>>> just follow the Trac workflow.
>>> Help is welcome in adding links to documentation for the various bits.
>>>
>>> I think we can have a fleshed out Trac to GitHub transition guide by the 
>>> end of the weekend.
>>>
>>>
>> A draft of the Trac-to-GitHub transition guide is now available at:
>> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
>>
>> Please let me know what's missing or unclear.
>>
>>
>
> Thanks, this is already in a pretty nice shape! I've extended some points 
> a bit.
>
> In my opinion, we can also directly drop the develop branch and move to 
> the master/main-branch only model. But that's slightly orthogonal to the 
> migration to Github.
>

-- 
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/7bbb0a76-1c97-485b-a133-d44d21ec52e3n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[seb....@gmail.com]

> I appreciate the efforts by Matthias and others to provide a roadmap for 
the proposed transition. 

+1

Nobody would buy a new house which has not been built yet without a good 
animation of how it would look like.

> Is there more than "trac is what we're used to"? Can those who are 
opposed please articulate the reasons?

I think it's natural that people want to know which advantages of the old 
house will be gone after the move. Therefore, we should not ask this 
question before the animation has finished.



John H Palmieri schrieb am Sonntag, 11. September 2022 um 01:23:16 UTC+2:

> I have heard lots of support for moving to GitHub, and I do not really 
> understand the arguments against. Is there more than "trac is what we're 
> used to"? Can those who are opposed please articulate the reasons?
>
> I appreciate the efforts by Matthias and others to provide a roadmap for 
> the proposed transition.
>
> -- 
> John
>
>
>
> On Saturday, September 10, 2022 at 4:19:37 PM UTC-7 Nathan Dunfield wrote:
>
>> I think moving to GitHub makes total sense.  Every other open-source math 
>> project I use regularly is on GH, and there are big network-effect benefits 
>> to being where everyone else is as others have already pointed out: easier 
>> for others to contribute, easier to get credit for contributions, easier 
>> cross references to issues up and downstream, etc.  Given the range of 
>> projects that use GH, including those like numpy and scipy whose issue/PR 
>> counts are similar to the number Sage trac tickets, I'm sure any technical 
>> or workflow issues have already been overcome by others and the solutions 
>> are likely even documented.  Given the open-source community's reliance on 
>> GH, any serious misbehavior on GH's part would result in a massive pushback 
>> and, if necessary, a concerted effort by a huge number of people to work 
>> out an alternative.
>>
>> Nathan
>>
>

-- 
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/fe87606e-502c-4762-ba63-76b39a885885n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[seb....@gmail.com]

dim...@gmail.com schrieb am Sonntag, 11. September 2022 um 01:36:31 UTC+2:

>
>
> On Sun, 11 Sep 2022, 00:22 seb@gmail.com,  wrote:
>
>> Matthias Koeppe schrieb am Samstag, 10. September 2022 um 21:32:50 UTC+2:
>>
>>> On Saturday, September 10, 2022 at 8:12:48 AM UTC-7 Matthias Koeppe 
>>> wrote:
>>>
>>>> I've added a draft of a proposed workflow on GitHub with the idea to 
>>>> just follow the Trac workflow.
>>>> Help is welcome in adding links to documentation for the various bits.
>>>>
>>>> I think we can have a fleshed out Trac to GitHub transition guide by 
>>>> the end of the weekend.
>>>>
>>>>
>>> A draft of the Trac-to-GitHub transition guide is now available at:
>>> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
>>>
>>> Please let me know what's missing or unclear.
>>>
>>
>>  What will be the replacement for the ticket description? Just the first 
>> comment of the issue reprectively PR? 
>>
>
> yes
>
> If so, who can edit it?
>>
>
> anyone with write access to the repo.
>
>
> https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-disruptive-comments#editing-a-comment
>

Thanks!
 

>
> -- 
>> 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/4420889b-a904-4ef8-9743-037648e7640cn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/4420889b-a904-4ef8-9743-037648e7640cn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/9363ef06-e271-418d-98bc-7972ca3e228dn%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[seb....@gmail.com]

Matthias Koeppe schrieb am Samstag, 10. September 2022 um 21:32:50 UTC+2:

> On Saturday, September 10, 2022 at 8:12:48 AM UTC-7 Matthias Koeppe wrote:
>
>> I've added a draft of a proposed workflow on GitHub with the idea to just 
>> follow the Trac workflow.
>> Help is welcome in adding links to documentation for the various bits.
>>
>> I think we can have a fleshed out Trac to GitHub transition guide by the 
>> end of the weekend.
>>
>>
> A draft of the Trac-to-GitHub transition guide is now available at:
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
>
> Please let me know what's missing or unclear.
>

 What will be the replacement for the ticket description? Just the first 
comment of the issue reprectively PR? If so, who can edit it?

-- 
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/4420889b-a904-4ef8-9743-037648e7640cn%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

[seb....@gmail.com]

kcrisman schrieb am Mittwoch, 27. April 2022 um 15:02:28 UTC+2:

On Tuesday, April 26, 2022 at 10:31:17 PM UTC-4 Matthias Koeppe wrote:
>
>> An update: The latest version of the installation manual (from 
>> https://trac.sagemath.org/ticket/33655) is available here: 
>> https://7896a56df78170d5bab0f306d1a7230986a4206a--sagemath-tobias.netlify.app/installation/index.html
>>
>>
> Thanks, much improved! 
>
+1

Eric Gourgoulhon schrieb am Dienstag, 26. April 2022 um 19:14:57 UTC+2:

It would be pretty easy to prepare a bash script executing all the commands 
listed in [1] and distribute that script from the download section of Sage 
home page. But I don’t know if this is a good idea (security issues?)

I think it’s a good idea to have such a script! I’ve opened ticket #33765 
 for that. Further 
discussion if it is a good idea or not can be done there. 
​

-- 
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/d2643732-c89d-44ab-ae57-1f94f755e625n%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

[seb....@gmail.com]

several Linux distributions carry reasonably up to date binary Sage 
installations (and these can be installed on various VMs, e.g. on Windows’ 
WSL, ChromeOS’ Crostini, etc)

For example current LinuxMint and WSL are both on Ubuntu 20.04 LTS which 
gives you Sage 9.0 (as in the example I’ve mentioned above). To get Sage 
9.5 you need Ubuntu 22.04 (I guess not very widespread at the moment). My 
point is the following: until we discontinued the binary tarballs, the 
straight ahead way to a Sage installation for Ubuntu systems lead you to 
the current release. This is broken, now.

The installation manual for 9.6 will look like this: 
https://6212659123a9467b3cb0cd07--sagemath-tobias.netlify.app/installation/index.html
There’s a decision tree.

Looks good. But, according to your sentence:

I agree, we should update our documentation to warn people about wildly 
outdated distribution packages on outdated OS distributions, and steer 
users to using conda-forge.

I would have expected that the *no root access* question comes first and 
perhaps reads like this: *no root access or older OS distribution*.

All - https://www.sagemath.org/ now has a revised Download menu - please 
take a look.

No doubt, this improves the situation a lot! But I think someone visiting 
our web-page the first time will rather push the *big blue button Download 
9.5* instead of going to the download menu especially if he wants to be 
sure to get the current release. This launches this page 
. But the chance to receive the 
promised release from there went down tremendously since we discontinued 
the binary tarballs. Don’t get me wrong: I completely understand that we 
don’t continue the tarballs for maintenance reasons, but I think there are 
further adaptions needed.
​
kcrisman schrieb am Dienstag, 26. April 2022 um 14:15:51 UTC+2:

> If we're moving away from providing binaries, then this is a good way to 
> go, well organized.  Below a few minor notes about the sagemath-tobias 
> link, I hope they are helpful.  My apologies in advance for any bike 
> shedding, though I tried to be pretty concrete.
>
> 1. Is it possible to have a short bullet list for the three/four options
> * Linux
> * Mac
> * Windoze
> * Cloud
> that link to those, immediately below "Where would you like to run 
> SageMath?"?  I'm pretty sure Sphinx makes that possible.  Even a little bit 
> of needed scrolling leads to people just not caring.
>
> 2. I'd also recommend Linux be last - this page is designed for people who 
> are not comfortable installing source software, I guess.  (Similarly, no 
> development as first option?)
>
> e. Alternately, one could have the first decision point be "develop or 
> not" - that would be my preference, but obviously would be an annoying bit 
> of work with perhaps not that much marginal gain.  Still, that seems to be 
> the great divide in Sage, not so much platform, and would allow for people 
> who want to just use Sage in the cloud to see that option very early.  It's 
> not like people on (say) Windows don't also use the cloud, so the four-way 
> partition could be somewhat misleading to less careful readers (which many 
> internet users are when in a hurry) in practice, though of course not in 
> principle.
>
> 3. Do the binaries/packaging allow for all optional packages and/or using 
> Cython/Fortran?  I recall this coming up not only on this list, but also 
> sometimes when I've tried to show people Cython usage as a "great feature" 
> of Sage that doesn't work in some environments.  If the answer to any of 
> these is not, you might need another part of the decision tree, or at least 
> a link to something about optional packages in each "no development" part.
>
> 4. A link to some Windows doc on what WSL is would probably be pretty 
> helpful, since presumably a lot of Windows users who like doing math have 
> never heard of it.
>

-- 
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/d7c62057-9492-43b1-8a14-7892b92b490dn%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

[seb....@gmail.com]

Actually we no longer advertise the binary distribution.

So, what do we advertise to potential newcomers to Sage? I think despite 
such great things as Cocalc, SageMathCell and Gitpod, there should be 
something easy to install that can be used offline, too.

This could be done in https://trac.sagemath.org/ticket/33655 
(Website/wiki/documentation: Streamline entry points for installation and 
development). Needs help!!

Thanks! I will have a look at it.

even if it’s not a priori discoverable for new users of Sage.

It is discoverable for new users! For example via sage -h or 
FeatureNotPresentError:

sage: c = CremonaDatabase('cremona')
Traceback (most recent call last):
...
FeatureNotPresentError: database_cremona_ellcurve is not available.
'cremona.db' not found in any of 
['/home/sebastian/devel/sage/local/share/cremona']
No equivalent system packages for debian are known to Sage.
To install database_cremona_ellcurve using the Sage package manager, you can 
try to run:
  !sage -i database_cremona_ellcurve
No equivalent system packages for pip are known to Sage.
Further installation instructions might be available at 
https://github.com/JohnCremona/ecdata.

This only works if you don’t ever want to e.g. rename sage to sage.in to 
fix the copy & paste from the other thread.

To be honest: I didn’t look at these difficulties either (so far). I’m just 
saying what I think should be our aim.

Neither approach assumes anything, but using “make” is at least familiar to 
anyone who has built any unix software in the past 30 years

Surely we all agree that make is a milestone in the development of software 
technology. Nevertheless it might not be familiar to young people (not even 
young developers who have grown up with gradle).

This is a null measure set of Windows users (and probably of Mac users). 
Especially of undergrad students, which are (or should be) a very sizable 
portion of our intended audience.

Exactly! If they would not belong to our intended audience, Sage would have 
no chance to stay alive.
​
emanuel.c...@gmail.com schrieb am Samstag, 23. April 2022 um 17:37:16 UTC+2:

> Neither approach assumes anything, but using “make” is at least familiar 
> to anyone who has built any unix software in the past 30 years
>
> This is a null measure set of Windows users (and probably of Mac users). 
> Especially of undergrad students, which are (or should be) a very sizable 
> portion of our intended audience. Users working in corporate salt mines, 
> where Unix use raises the wrath of IT department (sometimes for good 
> reasons…) are another glaring case : my professional use of a Linux system 
> is tolerated because it predates our current IT department ; my (eventual) 
> successor won’t have the same arguments to oppose our IT corporate jailers…
>
> I’d favor any solution that allows installing optional packages without 
> having to require of the user to install, learn and use a development 
> environment. Encouraging them to acquiring this skill set is one thing, 
> forcing them to is quite another…
> ​
> Le vendredi 22 avril 2022 à 20:02:30 UTC+2, Michael Orlitzky a écrit :
>
>> On Fri, 2022-04-22 at 08:16 -0700, seb@gmail.com wrote: 
>> > 
>> > (./sage -i should be deprecated and removed…) 
>> > 
>> > — or just have ‘sage -i xyz’ do whatever ‘make xyz’ now does, perhaps. 
>> > 
>> > +1 
>> > 
>>
>> This only works if you don't ever want to e.g. rename sage to sage.in 
>> to fix the copy & paste from the other thread. 
>>
>>
>> > Replacing sage -i xyz by make xyz sounds like assuming *all Sage users 
>> are 
>> > developers*. 
>>
>> Neither approach assumes anything, but using "make" is at least 
>> familiar to anyone who has built any unix software in the past 30 
>> years. The ad-hoc "sage" stuff is a priori familiar to no one and 
>> prevents us from modernizing lots of old cruft. 
>>
>>
>>

-- 
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/c4bec490-9bd8-4b04-b1d5-7851cc82bd33n%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

[seb....@gmail.com]

(./sage -i should be deprecated and removed…)

— or just have ‘sage -i xyz’ do whatever ‘make xyz’ now does, perhaps.

+1

Replacing sage -i xyz by make xyz sounds like assuming *all Sage users are 
developers*. make xyz doesn’t work if the current directory isn’t SAGE_ROOT 
or if make doesn’t exist on the system. Our advice in 
_spkg_installation_hint to install an optional package is still sage -i.

If we don’t support optional packages for binary distribution, we should 
make it clear in the installation guide. Otherwise we need to make sure 
this works (at least for packages that just copy one file or can be 
installed by pip).

At the moment both methods don’t work for binary distribution. Regarding sage 
-i see for example this post 
 along 
with this update 
. 
Regarding make, I verified this on the ubuntu:latest docker image by 
following both binary install instructions from our guide.

BTW: It seems that things became harder for newcomers to Sage to get it’s 
current version installed from binaries. Tarballs for 9.5 are not available 
on download mirrors anymore. For Ubuntu users the hint to use the systems 
standard package managers leads to an old version (9.0) (assuming most of 
them would use apt before installing conda, see for examples this thread 
). 
Another irritation: command-not-found tells you:

Command 'sage' not found, but can be installed with:
sudo apt install sagemath-common

But if you do that it will end up with a failure.
​
john.c...@gmail.com schrieb am Montag, 31. Januar 2022 um 21:13:41 UTC+1:

> On Mon, 31 Jan 2022 at 20:07, Dima Pasechnik  wrote:
> >
> >
> >
> > On Mon, 31 Jan 2022, 20:01 John Cremona,  wrote:
> >>
> >>
> >>
> >> On Mon, 31 Jan 2022, 17:12 Sébastien Labbé,  wrote:
> >>>
> >>> The "./configure" part of the installation of sage advice this:
> >>> database_cremona_ellcurve-20190911: optional, use "./configure 
> --enable-database_cremona_ellcurve" to install
> >>>
> >>> Therefore, if I were you, after updating the source tree with git 
> let's say, I would do:
> >>>
> >>> make configure
> >>> ./configure --enable-database_cremona_ellcurve
> >>> MAKE='make -j8' make
> >>>
> >>> to compile sagemath in parallel such a way that it automatically 
> installs the desired optional packages in whatever ordering respecting the 
> dependencies which works.
> >>>
> >>> You may also want more such "enable" as follows:
> >>>
> >>> ./configure \
> >>> --enable-experimental-packages \
> >>> --enable-download-from-upstream-url \
> >>> --enable-ccache \
> >>> --enable-database_cremona_ellcurve
> >>>
> >>> You may consult the config.log file which lists a lot of them.
> >>>
> >>> Sincerely,
> >>>
> >>> Sébastien
> >>
> >>
> >> Thanks for that. Some of us have been building Sage from source for a 
> long time (14 years!) which means we are set in our ways and just do what 
> we have always done.
> >>
> >> On the other hand it should surely be possible to install a package as 
> simple as this one without triggering a full rebuild, completely 
> unnecessarily, instead having to know before starting every optional 
> package one might ever need.
> >
> >
> > you can run ./configure as above after running make, you don't typically 
> have to do this from scratch.
> >
> > one also should be able to run
> >
> >
> > make database_cremona_ellcurve
>
> Dime, you're a hero -- that worked perfectly just as sage -i used to.
>
> >
> >
> > (./sage -i should be deprecated and removed...)
>
> -- or just have 'sage -i xyz' do whatever 'make xyz' now does, perhaps.
>
> John
>
> >
> >
> >>
> >>>
> >>>
> >>> On Monday, January 31, 2022 at 5:57:08 PM UTC+1 john.c...@gmail.com 
> wrote:
> 
>  [copied from sage-release]
> 
>  -- Forwarded message -
>  From: John Cremona 
>  Date: Mon, 31 Jan 2022 at 13:47
>  Subject: Re: [sage-release] Re: Sage 9.5 released
>  To: 
> 
> 
>  I just successfully built 9.5 from a fresh tarball. After completing
>  the build I installed (as I usually do) an optional package with the
>  command-line "./sage -i database_cremona_ellcurve" and now it is
>  rebuilding gmp. What is going on here? Has the way of installing
>  optional packages changed -- in which case, surely the use of "sage
>  -i" should tell you what to do instead, instead of doing the 'wrong'
>  thing?
> 
>  John
> 
>  PS In the end it seemed to rebuild just about everything, even though
>  installing that package only involves copying one data file; it took a
>  couple of hours. It would be nice to know how to avoid it happening
>  again (I have several other machines I want to install Sage on and I
>  do always need this package;))
> >>>
> >>> --
> >>> You received this message because 

Re: [sage-devel] Re: 32768

[seb....@gmail.com]

I have a 12 year old Acer AO Happy netbook (on Intel Atom CPU) which I'm 
running under LinuxMint. If I plan to do non CPU consuming work on the way 
to my office in subway trains and buses I still prefer it against a 
ThinkPad X240 because of weight, size and ergonomics. It still runs longer 
with its original battery as the ThinkPad with two batteries one of which I 
had to renew a year ago. In addition, for me its a matter of sustainability 
to use things as long as they work.

With Sage 9.4 I had to upgrade the LinuxMint from 17.3 to 19.3 which is the 
toplevel 32 bit LinuxMint. I hope that we will keep that for a while...

Building Sage from scratch nearly took a whole weekend. Currently I'm 
running Sage 9.5.beta3 on it with no problems.


wst...@gmail.com schrieb am Dienstag, 18. Januar 2022 um 17:38:07 UTC+1:

> On Tue, Jan 18, 2022 at 8:32 AM Matthias Koeppe  
> wrote:
>
>> On Tuesday, January 18, 2022 at 7:54:19 AM UTC-8 wst...@gmail.com wrote:
>>
>>> Who will solve ticket #32768 -- https://trac.sagemath.org/ticket/32768 
>>>
>>> "centos-7-i386: SIGFPE while building dochtml"
>>
>> with no other information at all.
>>
>>
>> You can reproduce this failure by typing "tox -e 
>> docker-centos-7-i386-standard".
>>
>> My on topic question (given the power of 2 discussion) is: 
>>>
>>> I'm curious -- what is the situation is with Sage and 32-bit Linux?
>>
>>
>> Supported, see list of platforms in 
>> https://wiki.sagemath.org/ReleaseTours/sage-9.5#Sources
>> as tested on each release tag on GH Actions. 
>>
>
>
> Amazing.  Does anybody reading this use 32-bit Linux?
>
>
>
>>
>> -- 
>> 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/0fd7769f-fe6e-4d16-b5d2-59fb6164b6fdn%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
> -- William Stein
>

-- 
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/6baba79b-c13a-4727-b03c-19a08400162cn%40googlegroups.com.

Re: [sage-devel] Re: Interface to Mathics

[seb....@gmail.com]

I don't know anything shorter than their release notes 
<https://github.com/mathics/Mathics/releases>. Therefore, I forwarded your 
question to Rocky Bernstein.

At least *Mathics* covers all of the functionality touched by our doctests 
of the *Mathematica* interface, except one function (FindMinimum). On the 
other hand, my impression is that there is still a lot of work to do until 
you can read in larger *Mathematica* packages and they just work.


wst...@gmail.com schrieb am Dienstag, 7. September 2021 um 21:48:17 UTC+2:

> Question: I didn't go to that talk, and I wasn't able to find slides
> or video. I looked on Github and it appears that Mathics has seen a
> flurry of development activity during the last year (yeah!!). Is
> there a 1-minute summary of the status of where it's at as a project?
>
> -- William
>
> On Tue, Sep 7, 2021 at 3:16 AM seb@gmail.com  
> wrote:
> >
> > This is ready for review, now!
> >
> > seb@gmail.com schrieb am Mittwoch, 5. Mai 2021 um 15:17:45 UTC+2:
> >>
> >>
> >> Dear all,
> >>
> >> those who participated in the Sage Days 110 may remember a talk about 
> Mathics.
> >> This is an open source interpreter for the Wolfram Language. I think it 
> would be a good enhancement for Sage to have an interface to it. This would 
> enable
> >> people (like me) that don't have access to a system possessing a 
> Mathematica licence to use functionality being written in WL inside Sage.
> >>
> >> I already wrote some code to start up the realization of such an 
> interface in #31778.
> >>
> >> Any contribution to this is welcome!
> >>
> >> Especially, I would appreciate if people that have more experiences 
> with this kind of interfaces than I do (which is almost nothing) could have 
> a look at the code!
> >>
> >> Best
> >> Sebastian
> >>
> > --
> > 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/ba4034af-7ad2-492a-83ea-ae068912f9c7n%40googlegroups.com
> .
>
>
>
> -- 
> 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/81033343-55f9-4fc0-b528-a09c17b1f982n%40googlegroups.com.

[sage-devel] Re: Interface to Mathics

[seb....@gmail.com]

This is ready for review, now!

seb@gmail.com schrieb am Mittwoch, 5. Mai 2021 um 15:17:45 UTC+2:

>
> Dear all,
>
> those who participated in the Sage Days 110  may remember a talk 
> <https://researchseminars.org/talk/SageDays110/23/> about Mathics 
> <https://mathics.org/>.
> This is an open source interpreter for the Wolfram Language. I think it 
> would be a good enhancement for Sage to have an interface to it. This would 
> enable
> people (like me) that don't have access to a system possessing a 
> Mathematica licence to use functionality being written in WL inside Sage.
>
> I already wrote some code to start up the realization of such an interface 
> in #31778 <https://trac.sagemath.org/ticket/31778>.
>
> Any contribution to this is welcome!
>
> Especially, I would appreciate if people that have more experiences with 
> this kind of interfaces than I do (which is almost nothing) could have a 
> look at the code!
>
> Best
> Sebastian
>
>

-- 
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/ba4034af-7ad2-492a-83ea-ae068912f9c7n%40googlegroups.com.

Re: [sage-devel] Re: How much do we support the casual user

[seb....@gmail.com]

FYI: Note that there currently is a ticket(#32321 
) to make changes to the global 
`is_prime` function treating the subject discussed here.


wst...@gmail.com schrieb am Dienstag, 10. April 2018 um 07:02:18 UTC+2:

> On Mon, Apr 9, 2018 at 8:12 PM saad khalid  wrote:
>
>> Have we come to any conclusions on what steps should be taken after this 
>> topic? What seems to be the concensus? Or, at the very least, could someone 
>> give a listing of the options we have so that we can give it a poll or 
>> something similar?
>>
>
>
> My favorite is to add a once per session warning to the the global 
> is_prime function the first time it receives a field element.  Absolutely 
> no other changes at all. 
>
>
>>
>> On Monday, April 2, 2018 at 2:58:36 AM UTC-5, Sebastian Oehms wrote:
>>>
>>> Hello,
>>>
>>> This topic is a good example, that wrong names can be worse than wrong 
>>> code.
>>>
>>> Only the user knows what he has in mind using the adjective "prime":
>>>
>>> 1) prime in a "narrower sense": being a prime number
>>> 2) prime in a "broader sense":  being a prime element of a unital 
>>> commutative ring 
>>>
>>> Therefore, the user must have the possibility to solve this ambiguity.
>>>
>>> If we will do that by an optional argument (as suggested by Erik Bray), 
>>> then we have to fix a default! Taking the default to be 1) would prefer the 
>>> casual user and keep track with popular CAS. 
>>>
>>> WolframAlpha answers the question "is 3/1 prime?" in the sense of 1) 
>>> with "true". If you have 2) in mind this seems to be a bug. But to be fair: 
>>> The result "true" matches the explanation WolframAlpha gives for the 
>>> adjective "prime" (namely according to 1)). If you ask "is 3/1 a prime 
>>> element?" then it shows you the definition of "prime element" but does not 
>>> calculate any thing.
>>>
>>> Now, Sage can calculate this, and accordingly gives the answer in the 
>>> sense of 2) like mathematicians would expect. Does it so, always?
>>>
>>> sage: is_prime(I)
>>>
>>> ---
>>> TypeError Traceback (most recent call 
>>> last)
>>> 
>>> TypeError: Unable to coerce I to an integer
>>>
>>>
>>> This looks as if even Sage is trying to give the answer according to 1), 
>>> as well!
>>>
>>> Nevertheless, taking 2) as default would raise less compatibility 
>>> problems (and seems to be the favorite in most of the contributions of this 
>>> thread).
>>>
>>> But anyway, IMHO the best thing would be to follow the suggestion of 
>>> Eric Gourgoulhon, solving the ambiguity by separated function names. But if 
>>> the name "is_prime" should survive, you will have to make a 
>>> "default"-decision, as well.
>>>
>>>
>>> As a newcomer to sage-devel I cannot really say, how painful the most 
>>> transparent solution would be, but I think it should be taken into account, 
>>> too:
>>>
>>> Deprecation of "is_prime" as function (not as method!!! since there is 
>>> no ambiguity here) and replace it by two new functions "is_prime_number" 
>>> and "is_prime_element" (according to the corresponding Wikipedia articles). 
>>> The first function should try to coerce the input into ZZ and raise an 
>>> error if this it not possible or not positive. The second one should raise 
>>> an error if the input is not an element of a unital commutative ring and a 
>>> warning in the case the ring is a field (according to 
>>> https://trac.sagemath.org/ticket/25046). In cases as for the 
>>> SymbolicRing above a NotImplementedError should be raised.
>>>
>>> If you think deprecation of "is_prime()" would be to painful, then which 
>>> of both ("is_prime_number" or "is_prime_element") should keep the name 
>>> "is_prime"? I found contributions for both possibilities!
>>>
>>> Best,
>>> Sebastian
>>>
>> -- 
>>
> 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 post to this group, send email to sage-...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> -- William Stein
>

-- 
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/57ca415d-0f80-4778-9f06-bc06105266c2n%40googlegroups.com.

[sage-devel] Interface to Mathics

[seb....@gmail.com]

Dear all,

those who participated in the Sage Days 110  may remember a talk 
 about Mathics 
.
This is an open source interpreter for the Wolfram Language. I think it 
would be a good enhancement for Sage to have an interface to it. This would 
enable
people (like me) that don't have access to a system possessing a 
Mathematica licence to use functionality being written in WL inside Sage.

I already wrote some code to start up the realization of such an interface 
in #31778 .

Any contribution to this is welcome!

Especially, I would appreciate if people that have more experiences with 
this kind of interfaces than I do (which is almost nothing) could have a 
look at the code!

Best
Sebastian

-- 
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/7699f297-d0f9-4e8c-8c47-0d5d52d5c07bn%40googlegroups.com.

[sage-devel] Re: Running MathicsSession inside Sage

[seb....@gmail.com]

Thanks to everyone who helped here somewhere along the way!

rocky.b...@gmail.com schrieb am Freitag, 26. März 2021 um 23:52:54 UTC+1:

> I asked about this in the mpmath group and the solution there I think is 
> good and only requires a change (or rather simplification) to the Mathics 
> code.
>
> So as far as I am concerned no changes are needed to sage or mpmath. See 
> https://groups.google.com/g/mpmath/c/qzA5gs57Qm8/m/_eg4GHisAAAJ
>
> On Friday, March 26, 2021 at 6:47:32 PM UTC-4 dim...@gmail.com wrote:
>
>> On Thursday, March 25, 2021 at 2:24:43 PM UTC seb@gmail.com wrote:
>>
>>> Hi,
>>>
>>> Did anyone try this before? At the moment this stucks at the following 
>>> issue:
>>>
>>> sage: import mpmath
>>> sage: mpmath.ctx_mp_python.mpf
>>>
>>> ---
>>> AttributeErrorTraceback (most recent call 
>>> last)
>>>  in 
>>> > 1 mpmath.ctx_mp_python.mpf
>>>
>>> AttributeError: module 'mpmath.ctx_mp_python' has no attribute 'mpf'
>>>
>>
>> this is apparently easy to fix, as this is due to
>>
>> https://github.com/fredrik-johansson/mpmath/blob/bd6715df41f2034f4438a77acc9bb05d03564942/mpmath/ctx_mp.py#L54
>> which makes the import of mpf conditional on BACKEND not being 'sage'
>>
>> Making it unconditional does not seem to break anything in Sage.
>>
>>  
>>
>>>
>>>
>>> whereas
>>>
>>> ~/devel/sage$ ./local/bin/python3
>>> Python 3.9.2 (default, Mar 19 2021, 22:23:28)
>>> [GCC 7.4.0] on linux
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import mpmath
>>> >>> mpmath.ctx_mp_python.mpf
>>> 
>>>
>>>
>>> Any ideas what is the reason for this?
>>>
>>> For the background of this question see Mathics issue 1169 
>>> <https://github.com/mathics/Mathics/issues/1169>  especially this 
>>> comment 
>>> <https://github.com/mathics/Mathics/issues/1169#issuecomment-806587816>.
>>>
>>>

-- 
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/7ec21d2a-801a-4bc9-8c92-8be4e2bd112an%40googlegroups.com.

[sage-devel] Running MathicsSession inside Sage

[seb....@gmail.com]

Hi,

Did anyone try this before? At the moment this stucks at the following 
issue:

sage: import mpmath
sage: mpmath.ctx_mp_python.mpf
---
AttributeErrorTraceback (most recent call last)
 in 
> 1 mpmath.ctx_mp_python.mpf

AttributeError: module 'mpmath.ctx_mp_python' has no attribute 'mpf'


whereas

~/devel/sage$ ./local/bin/python3
Python 3.9.2 (default, Mar 19 2021, 22:23:28)
[GCC 7.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import mpmath
>>> mpmath.ctx_mp_python.mpf



Any ideas what is the reason for this?

For the background of this question see Mathics issue 1169 
  especially this comment 
.

-- 
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/2eeaf3dd-2762-475f-b073-ec205e0b945fn%40googlegroups.com.

Re: [sage-devel] issue with CRLF line endings

[seb....@gmail.com]

I had the exactly same issue a while ago and finally got rid of it after 
many tries. It even appeared after a fresh git clone. I had to unset all 
(not just core.autocrlf) global Git configurations except username and 
password, even push.default (which I do on all other Git repositories 
locally, now).

BTW: I suspect that the issue with the broken GitLab pipelines for Trac 
tickets  that I mentioned 
in this sage-devel thread 
 is 
related.

dim...@gmail.com schrieb am Donnerstag, 11. Februar 2021 um 12:24:27 UTC+1:

> It could also be that core.autocrlf is true by default for you.
> (this is the option that does automatic convesion to LF from CRLF)
> Try
>
> git config core.autocrlf false
>
> and see if it helps
>
> On Thu, Feb 11, 2021 at 9:21 AM John Cremona  wrote:
> >
> > On Wed, 10 Feb 2021 at 18:07, Dima Pasechnik  wrote:
> > >
> > > On Wed, Feb 10, 2021 at 5:49 PM John Cremona  
> wrote:
> > > >
> > > > On Wed, 10 Feb 2021 at 16:56, Dima Pasechnik  
> wrote:
> > > > >
> > > > > On Wed, Feb 10, 2021 at 2:58 PM John Cremona  
> wrote:
> > > > > >
> > > > > > Has anyone else been seeing the following problem, which has been
> > > > > > plaguing me for a week or two. Here's a simple example. All
> > > > > > computers mentioned here are running ubuntu. On a machine I had 
> not
> > > > > > used for a while I had a sage build of the develop branch at an 
> old
> > > > > > version (pre 9.0). There were no modified files (git status 
> showed
> > > > > > nothing). Then I did "git pull trac develop", after which one 
> file is
> > > > > > marked as having changed:
> > > > > >
> > > > > > modified: src/sage/misc/element_with_label.py
> > > > > >
> > > > > > It is always this file, on several machines where I have gone 
> through
> > > > > > similar steps. file shows this:
> > > > > > src/sage/misc/element_with_label.py: Python script, ASCII text
> > > > > > executable, with CRLF line terminators
> > > > >
> > > > > does
> > > > >
> > > > > git config core.autolf
> > > > >
> > > > > show 'true'?
> > > >
> > > > No.
> > > >
> > > > >
> > > > > Set it to false, IMHO this should fix this issue.
> > > >
> > > > It is not set at all. I saw that option after googling for help, but
> > > > the issue it exists to solve is not one which has ever hit me (in 
> sage
> > > > anyway, of course I know about using dos2unix sometimes when a 
> windows
> > > > users sends a file).
> > >
> > > did you try setting this option to false, and see if it helps?
> >
> > Not yet systematically. After setting it to false and doing nothing
> > else, git status still shows
> > src/sage/misc/element_with_label.py as modified, even after 'git
> > checkout --'. Trying to get back to sanity a different way, 'git
> > stash' now outputs
> >
> >
> > warning: CRLF will be replaced by LF in 
> src/sage/misc/element_with_label.py.
> > The file will have its original line endings in your working directory.
> > warning: CRLF will be replaced by LF in 
> src/sage/misc/element_with_label.py.
> > The file will have its original line endings in your working directory.
> > Saved working directory and index state WIP on develop: 8453ffb
> > Updated SageMath version to 9.3.beta7
> > HEAD is now at 8453ffb Updated SageMath version to 9.3.beta7
> >
> > but git status still shows that file as modified. Now I cannot just
> > checkout a different existing branch (since there are apparently
> > modified files), but I can checkout a new branch (g = alias for git)
> >
> > $ g co -b dud
> > M src/sage/misc/element_with_label.py
> > Switched to a new branch 'dud'
> >
> > the delete the 'develop' branch (which was the same as upstream anyway):
> >
> > $ g branch -d develop
> > Deleted branch develop (was 8453ffb).
> >
> > and now recreate the develop branch
> >
> > $ g remote update trac
> > (...)
> > $ g co -b develop trac/develop
> > M src/sage/misc/element_with_label.py
> > Branch develop set up to track remote branch develop from trac.
> > Switched to a new branch 'develop'
> >
> > and we are back to where we started. All of the above was with
> > core.autolf set to false.
> >
> > On the same machine, in a completely new clone made and built
> > yesterday, git status shows
> >
> > $ g st
> > On branch develop
> > Your branch is up-to-date with 'origin/develop'.
> > Changes not staged for commit:
> > (use "git add ..." to update what will be committed)
> > (use "git checkout -- ..." to discard changes in working directory)
> >
> > modified: src/sage/rings/invariants/__init__.py
> >
> > no changes added to commit (use "git add" and/or "git commit -a")
> >
> > So the same problem with a new file -- which only has 2 bytes in it!
> > AFter dos2unix-ing it (so it now has 1 byte) it is still showing up in
> > git status. AFter git checkout -- it goes back to having 2 bytes and
> > still shows up.
> >
> > It seems to be impossible to do any sage devel

[sage-devel] Re: missing docker images of sagemath

[seb....@gmail.com]

It seems that there is still (or again) something broken. For the images of 
the beta releases since the 8th of December Sage crashes if I try to start 
it:

Sage build/upgrade complete!
make[1]: Leaving directory '/home/sage/sage'
sage@8711c66abafe:~/sage$ ./sage
┌┐
│ SageMath version 9.3.beta5, Release Date: 2020-12-27   │
│ Using Python 3.8.5. Type "help()" for help.│
└┘
┏┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗┛

/home/sage/sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x6b28)[0x7ff042b33b28]
/home/sage/sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x6d08)[0x7ff042b33d08]
/home/sage/sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x93a0)[0x7ff042b363a0]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7ff0523f9390]
/home/sage/sage/local/lib/libgmp.so.10(__gmpz_sizeinbase+0x47)[0x7ff049df0597]
/home/sage/sage/local/lib/python3.8/site-packages/sage/rings/rational.cpython-38-x86_64-linux-gnu.so(+0x1f78c)[0x7ff036e2978c]
/home/sage/sage/local/lib/python3.8/site-packages/sage/rings/rational.cpython-38-x86_64-linux-gnu.so(+0x370d5)[0x7ff036e410d5]

/home/sage/sage/local/lib/libpython3.8.so.1.0(+0x185260)[0x7ff05278a260]
/home/sage/sage/local/lib/libpython3.8.so.1.0(PyRun_FileExFlags+0x95)[0x7ff05278cb45]
/home/sage/sage/local/lib/libpython3.8.so.1.0(PyRun_SimpleFileExFlags+0xf6)[0x7ff05278ccb6]
/home/sage/sage/local/lib/libpython3.8.so.1.0(Py_RunMain+0x748)[0x7ff0527a7398]
/home/sage/sage/local/lib/libpython3.8.so.1.0(Py_BytesMain+0x39)[0x7ff0527a77c9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ff05203e840]
python3(_start+0x29)[0x400709]

Attaching gdb to process id 9075.
Cannot find gdb installed
GDB is not installed.
Install gdb for enhanced tracebacks.

Unhandled SIGILL: An illegal instruction occurred.
This probably occurred because a *compiled* module has a bug
in it and is not properly wrapped with sig_on(), sig_off().
Python will now terminate.

Illegal instruction (core dumped)

Furthermore, all pipelines on individual branches since that date failed.
Frédéric Chapoton schrieb am Dienstag, 8. Dezember 2020 um 09:33:03 UTC+1:

> the build for 9.3.beta3 has passed successfully, so there should be a 
> docker for that, and a docker for develop that should point to the same.
>
> https://gitlab.com/sagemath/sage/-/pipelines
>
> Frédéric
>
> Le jeudi 15 octobre 2020 à 12:09:15 UTC+2, Sébastien Labbé a écrit :
>
>> Bonjour,
>>
>> Thanks to Vincent, I learned recently how to use continuous integration 
>> in gitlab and the docker images of previous versions of sage posted 
>> https://hub.docker.com/r/sagemath/sagemath-dev/ in order to test that my 
>> optional package works with all those versions. It basically made me 
>> realize that my package was broken on most versions of sage except the most 
>> recent. And hopefully soon, I will be able to fix those issues. So thanks 
>> to those involved in having these various docker images available.
>>
>> For the curious, the most recent run is available here:
>> https://gitlab.com/seblabbe/slabbe/-/pipelines/202932270
>> it shows that my package works for 9.1.rc5 but not 9.0 or earlier 
>> versions (I need to work on it).
>>
>> Unfortunately, it seems the docker images of various versions of sage are 
>> not uploaded since 4 months. Maybe it was too much energy to upload all 
>> beta versions there. In fact, I don't really need all beta in there. What I 
>> think is important to have are the final releases. With that respect, the 
>> following are missing:
>>
>> 8.6: ok
>> 8.7: ok
>> 8.8: ok
>> 8.9 is missing or is broken
>> 9.0 : ok
>> 9.1 is missing (so I am using 9.1.rc5 and 9.1.rc5-py3)
>>
>> No 9.2.betaX are there, but I would be happy that 9.2 be there when 
>> released.
>>
>> Thanks to the people involved.
>>
>> Sincerely,
>>
>> Sébastien
>>
>

-- 
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/1cb3c7fb-f98b-40e9-90c3-c1961235be43n%40googlegroups.com.