ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

[Dima Pasechnik]

So far we only had very few votes cast.

Once again, I think we should close ranks with the rest of scientific python people and start following NEP 29.

We have much more urgent stuff to work on - buggy Pynac, buggy Singular interface, etc, than the Python 3.8 retrocomputing.

Dima 

[David Joyner]

On Tue, May 30, 2023 at 5:15 AM Dima Pasechnik <dim...@gmail.com> wrote:

So far we only had very few votes cast.

I vote for following NEP 29, or, at the very least, staying as coordinated with numpy as possible.

 

Once again, I think we should close ranks with the rest of scientific python people and start following NEP 29.

We have much more urgent stuff to work on - buggy Pynac, buggy Singular interface, etc, than the Python 3.8 retrocomputing.

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

[Michael Orlitzky]

On Tue, 2023-05-30 at 10:15 +0100, Dima Pasechnik wrote:
> So far we only had very few votes cast.
>

We probably should have started with the discussion and then voted
afterwards. FWIW I'm still not sure.

I basically agree with Matthias's points. If (for example) supporting
python-3.8 costs us very little, then having a policy that forces us to
drop it would be worse than having a policy that allows us to weigh the
pros and cons and make our own decision.

On the other hand, no one is ever going to agree on the weights
assigned to those pros and cons. We've had this same discussion a few
times already, and this time around it's pretty clear that we're
keeping old versions around for too long.

We COULD just try to be less conservative when dropping support for
older versions, as opposed to adopting a policy that mandates it. But
do we really want to have this same fight every three months? I'm
leaning towards voting yes for that reason.

[William Stein]

On Tue, May 30, 2023 at 2:15 AM Dima Pasechnik <dim...@gmail.com> wrote:
>
> So far we only had very few votes cast.

You might want to consider structuring the voting process more. For
example, David Roe did a great job with this for the "move sage to
github"
vote, including a clear deadline, a thread where no discussion about
the vote is allowed (only a vote), etc.

William

>
> Once again, I think we should close ranks with the rest of scientific python people and start following NEP 29.
> We have much more urgent stuff to work on - buggy Pynac, buggy Singular interface, etc, than the Python 3.8 retrocomputing.
>
> 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/CAAWYfq1jJgs-mux97LcTR75ZgaQQDGZ6uGKUCkyfEyDAp1rqoQ%40mail.gmail.com.

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

[Dima Pasechnik]

On Tue, May 30, 2023 at 2:39 PM William Stein <wst...@gmail.com> wrote:
>
> On Tue, May 30, 2023 at 2:15 AM Dima Pasechnik <dim...@gmail.com> wrote:
> >
> > So far we only had very few votes cast.
>
> You might want to consider structuring the voting process more.

Well, have you notiiced that while casting his vote, Matthias wrote a
full screenful of questionable
explanations of why he voted "no", bringing ?
https://groups.google.com/g/sage-devel/c/3Zoq0CNE1hE/m/jRlh6NvQBwAJ
(and said that comments should not be on this thread).

Perhaps this should be considered a spoilt ballot, meant to derail the process.


While in my "ballot" I added a couple of sentenses, they were meant to
rectify the original
post requesting the vote.

> For
> example, David Roe did a great job with this for the "move sage to
> github"
> vote, including a clear deadline, a thread where no discussion about
> the vote is allowed (only a vote), etc.
>
> William
>
> >
> > Once again, I think we should close ranks with the rest of scientific python people and start following NEP 29.
> > We have much more urgent stuff to work on - buggy Pynac, buggy Singular interface, etc, than the Python 3.8 retrocomputing.
> >
> > 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/CAAWYfq1jJgs-mux97LcTR75ZgaQQDGZ6uGKUCkyfEyDAp1rqoQ%40mail.gmail.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+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CACLE5GA6U9PiCwZ6bZx0VbfbbfKaU1i6J%3DGtzyvZkrEz2VQ3LQ%40mail.gmail.com.

[Nils Bruin]

On Tuesday, 30 May 2023 at 07:17:17 UTC-7 Dima Pasechnik wrote:

While in my "ballot" I added a couple of sentenses, they were meant to
rectify the original
post requesting the vote.

 

I think it's clear that the vote was called prematurely -- there was clearly a need for people on the forum to see some discussion of the pros and cons. Even if those discussions were had elsewhere or prior already, when an issue is raised on sage-devel for a general vote, some discussion will be required. For synchronous, in-person meetings, Robert's Rules give a fairly widely accepted framework for organizing discussion and then proceeding to voting and decision. This makes me think we need Robert's Rules for online forum democratic discussion and decision making as well, but I wasn't able to locate a concise and sensible set of recommendations.

This is certainly not the first voting process that derailed on sage-devel, and it tends to happen in roughly the same way every time, and more frequently with items that probably looked fairly uncontentious to start with but for which it turns out there are some different opinions after all. Those need to be heard close to the vote, in a place near the vote.

The vote on transitioning to github was indeed a shining example of one where those issues were properly managed. It probably helped that it was clear from the start there were strong opinions on either side and that a decision had to be made, so that a clear and transparent process was required.

I'd say the process for NEP 29 has now become so muddled that it's better to start clean: Set a week (is that enough? do we need more?) for discussion, then open a thread collecting votes *ONLY* (no comments) for another week, count votes -- done.

I think experience has shown we are prone to underestimating the need for structure in voting, leading to more work when we don't. Hopefully some upfront investment in a reasonable procedure (even if it costs a full two weeks!)  leads to faster results with less acrimony than the attempts at light-weight, fast and nimble voting procedures that derail.

[Matthias Koeppe]

On Tuesday, May 30, 2023 at 2:15:57 AM UTC-7 Dima Pasechnik wrote:

Once again, I think we should close ranks with the rest of scientific python people and start following NEP 29.

We have much more urgent stuff to work on - buggy Pynac, buggy Singular interface, etc, than the Python 3.8 retrocomputing.

Here again it is implied that that "we" are doing work to maintain the Python 3.8 support that would get in the way of doing more important work.

This is unsubstantiated -- because it is simply not true. 

There was a single ticket which broke Python 3.8 support since we dropped Python 3.7 support (2022). It was caught by the automatic portability tests in the next beta, and then I made the (trivial) fix. That's all.

[Dima Pasechnik]

already the discussion on these minor points has taken so much time that we could have instead done 10 or 20 PRs, but apparently for you, Matthias, the priorities are elsewhere - defending your point of view takes  precedence over everything else.

I find it hugely damaging to the project.

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/3c440998-996d-425c-bee5-3abafb6534b4n%40googlegroups.com.

[Matthias Koeppe]

On Tuesday, May 30, 2023 at 9:14:14 AM UTC-7 Dima Pasechnik wrote:

already the discussion on these minor points has taken so much time that we could have instead done 10 or 20 PRs

This line of reasoning has been used several times already, including by you.

I have to point out that it is an invalid argumentative tactic: 

You are *assuming* that you are right, and then accuse me of blocking progress, and of wasting your time with the discussion; and then you demand that I give in, based on it. 

It is easy to make the mistake of overlooking that this is an invalid tactic, based on a circular reasoning fallacy. 

But if used deliberately, it is abusive behavior -- namely a form of bullying. As I wrote in https://github.com/sagemath/sage/pull/35404#issuecomment-1563435455, "Sage is a mature project that is developed in the open and in which also all decision making takes place in the open. Users and developers who decide to engage with a project such as Sage know that this is always a long-term investment on their side. They need to be able to trust that the project makes decisions in a meaningful, responsible way, which reduces their perceived risk in making this investment."

[William Stein]

+1. This is hard to disagree with. 

--
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/d459d557-fd7d-4c6a-8644-3ee96966b8fan%40googlegroups.com.

--

-- William Stein

[Matthias Koeppe]

On Tuesday, May 30, 2023 at 2:26:02 AM UTC-7 David Joyner wrote:

I vote for following NEP 29, or, at the very least, staying as coordinated with numpy as possible.

Note that our current practice does already coordinate with numpy/scipy: The developers who engage in the maintenance of the Sage distribution are aware of the release schedules and version support policies of these major dependencies, and they are an important factor in deciding to drop support for a particular Python version (or compiler versions etc.)

(I described our current practice in https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/x3qOdPB5BQAJ, which also comments on the specifics on NumPy/SciPy.)

As others have said, "following NEP 29" could mean a range of different specific policies for our project. 

But the proposed vote (Tobias's PR https://github.com/sagemath/sage/pull/35403/files) proposes to write a strict, prescriptive interpretation into the project''s policies.

As I wrote in https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/37VaO2t_AAAJ, I disagree with adopting this as a policy for our project because it is worse than our current practice.

[Nils Bruin]

Can we please clearly formulate what the motion is that is being discussed and voted on? As Volker pointed out, NEP 29 guarantees what versions are supported, i.e., it gives a lower bound to what we support. If we are adopting that, it would seem that we are trying to solve a problem that sage has been dropping versions *too soon*. From the discussion here I don't get the impression that's the issue.

Rather I get the impression the motivation is the perception that sage is presently supporting *too many* versions and that this is holding up development because it prevents upgrades and delays fixes because they are required to be adapted to be compatible with too many python versions. So if the latter is the case, is the proposal "sagemath does not guarantee of python versions beyond what is required to comply with NEP 29. No particular effort is made to make fixes and upgrades to sagemath work with python versions outside the window mandated by NEP 29."

(I doubt anyone is advocating to actively break support for python versions outside of the NEP 29 support window. Breakage will happen as-needed)

[Tobia...@gmx.de]

On Wednesday, May 31, 2023 at 12:01:04 AM UTC+8 Nils Bruin wrote:

I'd say the process for NEP 29 has now become so muddled that it's better to start clean: Set a week (is that enough? do we need more?) for discussion, then open a thread collecting votes *ONLY* (no comments) for another week, count votes -- done.

I agree completely this is a good process, and actually tried to follow the good example of the github voting thread (actually even copy & pasted some part of the posting). There have been previous discussions on this topic here on the mailing list and in a github issue and PR (https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ, https://github.com/sagemath/sage/issues/30384, https://github.com/sagemath/sage/pull/35403). Good to see that now there are more people participating in the discussion.

I'm happy to restart the vote, either now or in a week.

[Tobia...@gmx.de]

Sorry for the confusion. I forgot that there are different readings of NEP29 and that this lead to misunderstandings before. The proposed policy is that all python versions supported by NEP29 are also supported by sage (this is the lower bound) and that we normally drop support for older versions right after this support window (i.e. also adapt the drop schedule https://numpy.org/neps/nep-0029-deprecation_policy.html#drop-schedule). I've formulated an improved formulation for this policy at https://github.com/sagemath/sage/pull/35403#issuecomment-1566110884 which should hopefully clarify this point.

 

(Dropping support means increasing `python_requires` and removing github tests for this old version, i.e. similar to https://github.com/sagemath/sage/pull/35404 which is modeled on the PR drooping Python 3.7.)

[Tobia...@gmx.de]

On Wednesday, May 31, 2023 at 1:20:51 AM UTC+8 Matthias Koeppe wrote:

But the proposed vote (Tobias's PR https://github.com/sagemath/sage/pull/35403/files) proposes to write a strict, prescriptive interpretation into the project''s policies.

 The policy should serve as a guideline for "normal procedure" and not be "strict" and totalitarian (i.e. not a law). A PR dropping support of course still has to go through the usual review procedure, and departures from the normal drop schedule can discussed there and on the mailing list. 

[Dima Pasechnik]

On Tue, May 30, 2023 at 5:53 PM Matthias Koeppe
<matthia...@gmail.com> wrote:
>
> On Tuesday, May 30, 2023 at 9:14:14 AM UTC-7 Dima Pasechnik wrote:
>
> already the discussion on these minor points has taken so much time that we could have instead done 10 or 20 PRs
>
>
> This line of reasoning has been used several times already, including by you.
>
> I have to point out that it is an invalid argumentative tactic:
>
> You are *assuming* that you are right, and then accuse me of blocking progress, and of wasting your time with the discussion; and then you demand that I give in, based on it.

We have a disagreement on a policy, and you are in minority. Yet you
keep trying to block it by inventing alls sorts of nitpicks.
Therefore you are wrong - and you know it I suppose, you just can't stop.
I made you apologise on the last few days on one such totally
irrelevant nitpick, you want more of this fight to continue?

Fine, but the danger is that you'll get to develop Sage all by
yourself, as others will just walk away.
I'm certainly very close to quitting Sage developement.


.

>
> It is easy to make the mistake of overlooking that this is an invalid tactic, based on a circular reasoning fallacy.
>
> But if used deliberately, it is abusive behavior -- namely a form of bullying. As I wrote in https://github.com/sagemath/sage/pull/35404#issuecomment-1563435455, "Sage is a mature project that is developed in the open and in which also all decision making takes place in the open. Users and developers who decide to engage with a project such as Sage know that this is always a long-term investment on their side. They need to be able to trust that the project makes decisions in a meaningful, responsible way, which reduces their perceived risk in making this investment."
>

> --
> 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/d459d557-fd7d-4c6a-8644-3ee96966b8fan%40googlegroups.com.

[Nils Bruin]

On Tuesday, 30 May 2023 at 11:13:27 UTC-7 Tobia...@gmx.de wrote:

that we normally drop support for older versions right after this support window (i.e. also adapt the drop schedule https://numpy.org/neps/nep-0029-deprecation_policy.html#drop-schedule). I've formulated an improved formulation for this policy at https://github.com/sagemath/sage/pull/35403#issuecomment-1566110884 which should hopefully clarify this point.

 

(Dropping support means increasing `python_requires` and removing github tests for this old version, i.e. similar to https://github.com/sagemath/sage/pull/35404 which is modeled on the PR drooping Python 3.7.)

Formulated like this it would seem to me we could needlessly reduce the platforms that sage builds on: this suggests that the "drop Python 3.*" PR would get merged simply because it's time: in theory we could end up with a release where the sole commit is the dropping of support (in practice development is way too active for this). I would expect that such a PR would only get merged as a dependency of some other PR (that makes a fix, enhancement, or upgrades some other component).

I guess another reason might be because we dropped testing on that Python version: once we're not testing we wouldn't know when it breaks and only reactively upping python_requires after someone reports a failure is probably not so nice.

Having a policy that makes clear when such a drop PR is acceptable as a prerequisite for merging could save work and discussion. Numpy's schedule looks like a reasonable candidate for that.

[Matthias Koeppe]

On Tuesday, May 30, 2023 at 10:40:36 AM UTC-7 Nils Bruin wrote:

(I doubt anyone is advocating to actively break support for python versions outside of the NEP 29 support window. Breakage will happen as-needed)

Actually this is exactly what Tobias's PR https://github.com/sagemath/sage/pull/35404/files is doing.

It rejects system Python 3.8 and removes the support packages that are there to provide the support this version.

And unfortunately the proponents of this radical step have been aggressive in trying to push this change through, violating our standard procedures on how tickets are reviewed and our code of conduct.

[Matthias Koeppe]

On Tuesday, May 30, 2023 at 11:56:15 AM UTC-7 Dima Pasechnik wrote:

On Tue, May 30, 2023 at 5:53 PM Matthias Koeppe
<matthia...@gmail.com> wrote:
> You are *assuming* that you are right, and then accuse me of blocking progress, and of wasting your time with the discussion; and then you demand that I give in, based on it.

We have a disagreement on a policy, and you are in minority. 

Like many of your recent claims, also this one is unsubstantiated.

[Dima Pasechnik]

No, that's you, Matthias, who have been aggressivly imposing your
pesonal opnion on us there, refusing to read and to listen,
not the other way around. You have aslo rejected PRs "for lack of
vision", demanding a 5-year plan ahead, for removing an outdated
feature nobody, except your CI scripts, use.

>
> --
> 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/74ebffc9-860a-4d66-a423-794e1c4a1551n%40googlegroups.com.

[Dima Pasechnik]

"proponents of a radical step",
Removing support for the oldest Python3 version Sage supports IS NOT A
RADICAL STEP.
Stop this bs please.

[Dima Pasechnik]

On Tue, May 30, 2023 at 8:04 PM Matthias Koeppe

<matthia...@gmail.com> wrote:
>
> On Tuesday, May 30, 2023 at 11:56:15 AM UTC-7 Dima Pasechnik wrote:
>
> On Tue, May 30, 2023 at 5:53 PM Matthias Koeppe
> <matthia...@gmail.com> wrote:
> > You are *assuming* that you are right, and then accuse me of blocking progress, and of wasting your time with the discussion; and then you demand that I give in, based on it.
>
> We have a disagreement on a policy, and you are in minority.
>
>
> Like many of your recent claims, also this one is unsubstantiated.

Can you count to 2? You were the reviewer against the PR, me,and the
PR author, for the PR.
This is called majority vs minority.

>
> --
> 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/8a0c65b6-5fc5-4e3c-9910-0c6397d9b61dn%40googlegroups.com.

[Nils Bruin]

@dima, @matthias : this public forum is not an appropriate venue to discuss personal disagreements. From what you both write I get the impression you actually have a lot of common ground and only a few differences in opinion, but that personalities and discussion styles exaggerate the disagreements. I hope a moderator steps in to warn you about code of conduct and making discussions personal. In the mean time, stepping back and let things cool down is probably the better thing to do, since I don't see a positive outcome from continuing your current back-and-forth, and it's toxic for other people following the thread to be confronted by such discord between respected members of the community.

[Matthias Koeppe]

On Tuesday, May 30, 2023 at 12:00:53 PM UTC-7 Nils Bruin wrote:

On Tuesday, 30 May 2023 at 11:13:27 UTC-7 Tobia...@gmx.de wrote:

that we normally drop support for older versions right after this support window (i.e. also adapt the drop schedule https://numpy.org/neps/nep-0029-deprecation_policy.html#drop-schedule). I've formulated an improved formulation for this policy at https://github.com/sagemath/sage/pull/35403#issuecomment-1566110884 which should hopefully clarify this point.

 

(Dropping support means increasing `python_requires` and removing github tests for this old version, i.e. similar to https://github.com/sagemath/sage/pull/35404 which is modeled on the PR drooping Python 3.7.)

Formulated like this it would seem to me we could needlessly reduce the platforms that sage builds on: this suggests that the "drop Python 3.*" PR would get merged simply because it's time: in theory we could end up with a release where the sole commit is the dropping of support (in practice development is way too active for this).

Exactly, which is why I have opposed setting Tobias's PR to positive review. (Note that Volker's release scripts currently do not take dependencies or declared milestones into account.)

I would expect that such a PR would only get merged as a dependency of some other PR (that makes a fix, enhancement, or upgrades some other component).

Exactly, this has been our current practice. We create the drop ticket as a placeholder and then, when upgrades of packages are being considered by the volunteers who contribute to maintaining the Sage distribution, we use it as a dependency of those upgrade tickets. Making a good, balanced decision is then very easy with the facts gathered. This has worked well.

[Dima Pasechnik]

On Tue, May 30, 2023 at 8:01 PM Nils Bruin <nbr...@sfu.ca> wrote:
>
> On Tuesday, 30 May 2023 at 11:13:27 UTC-7 Tobia...@gmx.de wrote:
>
> that we normally drop support for older versions right after this support window (i.e. also adapt the drop schedule https://numpy.org/neps/nep-0029-deprecation_policy.html#drop-schedule). I've formulated an improved formulation for this policy at https://github.com/sagemath/sage/pull/35403#issuecomment-1566110884 which should hopefully clarify this point.
>
> (Dropping support means increasing `python_requires` and removing github tests for this old version, i.e. similar to https://github.com/sagemath/sage/pull/35404 which is modeled on the PR drooping Python 3.7.)
>
>
> Formulated like this it would seem to me we could needlessly reduce the platforms that sage builds on: this suggests that the "drop Python 3.*" PR would get merged simply because it's time: in theory we could end up with a release where the sole commit is the dropping of support (in practice development is way too active for this). I would expect that such a PR would only get merged as a dependency of some other PR (that makes a fix, enhancement, or upgrades some other component).

No, that's a wrong impression. With dropping support e.g. for 3.X we
unblock PRs/issues which explicity rely on Python being 3.(X+1)+.
We may also have some backported from 3.(X+1)+ packages in Sage that
we can blissfully drop.

And anyway, in not so distant future 3.X won't get any security fixes
- so why wait?
3.X has long stopped getting any but security fixes, it's a bugnest.

(all of the above is correct for X=8, including backported package)

>
> I guess another reason might be because we dropped testing on that Python version: once we're not testing we wouldn't know when it breaks and only reactively upping python_requires after someone reports a failure is probably not so nice.
>
> Having a policy that makes clear when such a drop PR is acceptable as a prerequisite for merging could save work and discussion. Numpy's schedule looks like a reasonable candidate for that.
>

> --
> 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/fb01c984-560a-47cf-af3d-789cb1502342n%40googlegroups.com.

[Dima Pasechnik]

On Tue, May 30, 2023 at 8:19 PM Matthias Koeppe
<matthia...@gmail.com> wrote:
>
> On Tuesday, May 30, 2023 at 12:00:53 PM UTC-7 Nils Bruin wrote:
>
> On Tuesday, 30 May 2023 at 11:13:27 UTC-7 Tobia...@gmx.de wrote:
>
> that we normally drop support for older versions right after this support window (i.e. also adapt the drop schedule https://numpy.org/neps/nep-0029-deprecation_policy.html#drop-schedule). I've formulated an improved formulation for this policy at https://github.com/sagemath/sage/pull/35403#issuecomment-1566110884 which should hopefully clarify this point.
>
> (Dropping support means increasing `python_requires` and removing github tests for this old version, i.e. similar to https://github.com/sagemath/sage/pull/35404 which is modeled on the PR drooping Python 3.7.)
>
>
> Formulated like this it would seem to me we could needlessly reduce the platforms that sage builds on: this suggests that the "drop Python 3.*" PR would get merged simply because it's time: in theory we could end up with a release where the sole commit is the dropping of support (in practice development is way too active for this).
>
>
> Exactly, which is why I have opposed setting Tobias's PR to positive review. (Note that Volker's release scripts currently do not take dependencies or declared milestones into account.)

No, that's not how you opposed the PR. 1st, you wrote "it's too early
for 10.0" - and indeed, we were close to the 10.0 release.
Then, after 10.0 release, you - rather unexpectedly - kept opposing
it, for very vague reasons, which you had very hard time to justify.
It all smelled of a dictatorship on your side - "I can block, because,
hey, we do everything by consensus in Sage, and I don't like it, hence
it won't happen".
The reason given by Nils above did not come up. You just keep twisting
the truth.

>
> I would expect that such a PR would only get merged as a dependency of some other PR (that makes a fix, enhancement, or upgrades some other component).
>
>
> Exactly, this has been our current practice. We create the drop ticket as a placeholder and then, when upgrades of packages are being considered by the volunteers who contribute to maintaining the Sage distribution, we use it as a dependency of those upgrade tickets. Making a good, balanced decision is then very easy with the facts gathered. This has worked well.
>
>

> --
> 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/54aac5b2-b4a9-49bb-993f-439218565576n%40googlegroups.com.

[G. M.-S.]

Dima and Matthias,

I completely agree with Nils.

Could you (both of you) take a short vacation from SageMath, please?

More globally, I propose to stop this discussion completely for a few days.

Thanks in advance.

Guillermo

On Tue, 30 May 2023 at 21:14, Nils Bruin <nbr...@sfu.ca> wrote:

@dima, @matthias : this public forum is not an appropriate venue to discuss personal disagreements. From what you both write I get the impression you actually have a lot of common ground and only a few differences in opinion, but that personalities and discussion styles exaggerate the disagreements. I hope a moderator steps in to warn you about code of conduct and making discussions personal. In the mean time, stepping back and let things cool down is probably the better thing to do, since I don't see a positive outcome from continuing your current back-and-forth, and it's toxic for other people following the thread to be confronted by such discord between respected members of the community.

--

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/42fb0b3a-3f1c-48de-9a30-377e9dcd41cfn%40googlegroups.com.

[Matthias Koeppe]

Hi Guillermo,

On Tuesday, May 30, 2023 at 12:59:54 PM UTC-7 G. M.-S. wrote:

Could you (both of you) take a short vacation from SageMath, please?

Thanks, that's an interesting suggestion. But I think Dima would prefer to go on vacation with his family, not with me. ;)

Matthias

 

[G. M.-S.]

Hi, you managed to make me laugh…  Thanks.

Anyway, we need you.  Both of you.

Best,

Guillermo

--

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/7028f581-e771-4d30-bbeb-9704a7b53302n%40googlegroups.com.

[Tobias Diez]

On Wednesday, 31 May 2023 at 03:00:53 UTC+8 Nils Bruin wrote:

On Tuesday, 30 May 2023 at 11:13:27 UTC-7 Tobia...@gmx.de wrote:

that we normally drop support for older versions right after this support window (i.e. also adapt the drop schedule https://numpy.org/neps/nep-0029-deprecation_policy.html#drop-schedule). I've formulated an improved formulation for this policy at https://github.com/sagemath/sage/pull/35403#issuecomment-1566110884 which should hopefully clarify this point.

 

(Dropping support means increasing `python_requires` and removing github tests for this old version, i.e. similar to https://github.com/sagemath/sage/pull/35404 which is modeled on the PR drooping Python 3.7.)

Formulated like this it would seem to me we could needlessly reduce the platforms that sage builds on: this suggests that the "drop Python 3.*" PR would get merged simply because it's time: in theory we could end up with a release where the sole commit is the dropping of support (in practice development is way too active for this). I would expect that such a PR would only get merged as a dependency of some other PR (that makes a fix, enhancement, or upgrades some other component).

Yes, in theory that could happen. Since its real work that someone has to put in to create a "drop Python 3.*" PR, I suspect that this persons needs to see a clear benefit before opening the PR. So I suspect that one first notices "oh shit, this doesn't work on Python x" and then proceeds to create a drop PR if its already past the NEP29 time window. But I'm happy to encode this practice in the policy. Do you have a suggestion for a formulation?

 

Having a policy that makes clear when such a drop PR is acceptable as a prerequisite for merging could save work and discussion. Numpy's schedule looks like a reasonable candidate for that.

That was exactly my intention.

[Kwankyu Lee]

I think the voting should be about the policy about when to drop old python from sage support. There should be two candidates

Candidate T: Tobias' proposal to adopt NEP 29. Tobias may summarize the content of NEP 29.

Candidate M: Matthias' current practice. But this practice should be formulated as clearly as NEP 29.

[Dima Pasechnik]

I think this gives in to vote de-railers.

Besides, the 2nd option is just some ad hoc hogwash. Or do you propose to vote on appointing Matthias a (not so B)DFL ?

--
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/899d3b45-0c26-42b4-873a-c8533b473a4fn%40googlegroups.com.

[Kwankyu Lee]

 

Besides, the 2nd option is just some ad hoc hogwash. Or do you propose to vote on appointing Matthias a (not so B)DFL ?

No. I suggest him to formulate the practice as an objective checklist, so that voters know that rejecting the 1st option would not mean appointing DFL.

[kcrisman]

Anyway, we need you.  Both of you.

+1 

[Matthias Koeppe]

As service for those who are missing the references:

- BFDL = Benevolent Dictator for Life, which was used as the humorous title expressing the Python's community's trust in Guido van Rossum's leadership in Python development. Dima's use of the phrase "(not so B)FDL" insinuates that my work on Sage is not done with good intentions.

- vote-derailer - repeats Dima's accusation in https://groups.google.com/g/sage-devel/c/sVeu16vaEqo/m/gUr4lhZkAQAJ

- 5-year plan (appeared in https://groups.google.com/g/sage-devel/c/sVeu16vaEqo/m/D4pewORzAQAJ and previously in https://github.com/sagemath/sage/pull/35404#issuecomment-1505048255) = refers to a practice of the Soviet union introduced by Stalin and later by other countries in the Eastern Bloc. The first Soviet 5-year plan led to millions of deaths by famine. This reference is particularly offensive because both Dima and I grew up in the Eastern Bloc.

https://github.com/sagemath/sage/blob/develop/CODE_OF_CONDUCT.md

[Dima Pasechnik]

On Wed, May 31, 2023 at 6:23 PM Matthias Koeppe
<matthia...@gmail.com> wrote:
>
> As service for those who are missing the references:
>
> - BFDL = Benevolent Dictator for Life, which was used as the humorous title expressing the Python's community's trust in Guido van Rossum's leadership in Python development. Dima's use of the phrase "(not so B)FDL" insinuates that my work on Sage is not done with good intentions.

Benevolent also means "kind".

>
> - vote-derailer - repeats Dima's accusation in https://groups.google.com/g/sage-devel/c/sVeu16vaEqo/m/gUr4lhZkAQAJ
>
> - 5-year plan (appeared in https://groups.google.com/g/sage-devel/c/sVeu16vaEqo/m/D4pewORzAQAJ and previously in https://github.com/sagemath/sage/pull/35404#issuecomment-1505048255) = refers to a practice of the Soviet union introduced by Stalin and later by other countries in the Eastern Bloc. The first Soviet 5-year plan led to millions of deaths by famine. This reference is particularly offensive because both Dima and I grew up in the Eastern Bloc.

Offensive? You seem to find this offensive now, but making similar is
spirit remarks about my alledged lack of knowledge of English,
or me being deeply Soviet in my mind, or I f**king don't know what, as in
https://github.com/sagemath/sage/issues/32532#issuecomment-1418146524
is OK for you?
I quote:

> Ah, this is a common confusion. gcc is a standard package - in this case the word is spelled "standard" but it's pronounced "base".
> I think this complicated situation is due to the 1918 spelling reform.

(Remark: there was a spelling reform of Russian 1918 in USSR, cf. wikipedia)

By the way, it's from https://github.com/sagemath/sage/issues/32532 -
another nice example of Matthias not bothering to reply, just putting
'-1'
as his verdict.
Another example of him abusing the consensus idea of Sage developement
(it only works as long as everybody makes an effort to see
the other p.o.v. - otherwise it's a sure way to nowhere).


Dima

>
> https://github.com/sagemath/sage/blob/develop/CODE_OF_CONDUCT.md
>
> On Wednesday, May 31, 2023 at 3:20:56 AM UTC-7 Dima Pasechnik wrote:
>>
>>
>>
>> On Wed, 31 May 2023, 08:12 Kwankyu Lee, <ekwa...@gmail.com> wrote:
>>>
>>> I think the voting should be about the policy about when to drop old python from sage support. There should be two candidates
>>>
>>> Candidate T: Tobias' proposal to adopt NEP 29. Tobias may summarize the content of NEP 29.
>>> Candidate M: Matthias' current practice. But this practice should be formulated as clearly as NEP 29.
>>>
>>>
>>
>> I think this gives in to vote de-railers.
>> Besides, the 2nd option is just some ad hoc hogwash. Or do you propose to vote on appointing Matthias a (not so B)DFL ?
>>
>>>
>>> --
>>> 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/899d3b45-0c26-42b4-873a-c8533b473a4fn%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/043c5348-f889-4be9-af33-d8d2560dfe3an%40googlegroups.com.

[John H Palmieri]

On Tuesday, May 30, 2023 at 12:59:54 PM UTC-7 G. M.-S. wrote:

Dima and Matthias,

I completely agree with Nils.

Could you (both of you) take a short vacation from SageMath, please?

More globally, I propose to stop this discussion completely for a few days.

+100

It's time for this discussion to stop.

[Matthias Koeppe]

On Wednesday, May 31, 2023 at 11:00:58 AM UTC-7 Dima Pasechnik wrote:

On Wed, May 31, 2023 at 6:23 PM Matthias Koeppe
<matthia...@gmail.com> wrote:

> As service for those who are missing the references: [...]

>
> - 5-year plan (appeared in https://groups.google.com/g/sage-devel/c/sVeu16vaEqo/m/D4pewORzAQAJ and previously in https://github.com/sagemath/sage/pull/35404#issuecomment-1505048255) = refers to a practice of the Soviet union introduced by Stalin and later by other countries in the Eastern Bloc. The first Soviet 5-year plan led to millions of deaths by famine. This reference is particularly offensive because both Dima and I grew up in the Eastern Bloc.

Offensive? You seem to find this offensive now, but making similar is
spirit remarks about my alledged lack of knowledge of English,
or me being deeply Soviet in my mind, or I f**king don't know what, as in
https://github.com/sagemath/sage/issues/32532#issuecomment-1418146524
is OK for you?
I quote:

> Ah, this is a common confusion. gcc is a standard package - in this case the word is spelled "standard" but it's pronounced "base".
> I think this complicated situation is due to the 1918 spelling reform.

(Remark: there was a spelling reform of Russian 1918 in USSR, cf. wikipedia)

By the way, it's from https://github.com/sagemath/sage/issues/32532 

I'm sorry to hear that you were offended by that, I had no idea. It definitely was not my intention.

To the contrary, I was referring to my (limited) knowledge of the Russian language and its development as a reminder of our friendly in-person interactions when you visited me in Berkeley and Davis --- which now seems ages ago.

I'll now explain the joke: 

- "base" referred to the special status of some "standard" packages as in https://github.com/sagemath/sage/blob/develop/build/make/Makefile.in#L256 and some loose ends in the source code related to that, https://github.com/sagemath/sage/blob/develop/build/sage_bootstrap/package.py#L327

- the 1918 spelling reform of Russian consolidated some vowels, rendering some entirely unrelated words to be spelt the same (I'm not sure whether also pronounced the same)

- the phrase "the word is spelt '...' but it's pronounced '(something obviously unrelated)" is a reference to a popular Monty Python sketch that involves a character named Raymond Luxury-Yacht whose name is pronounced quite unrelated to this spelling.

[Dima Pasechnik]

On Wed, May 31, 2023 at 7:33 PM Matthias Koeppe

<matthia...@gmail.com> wrote:
>
> On Wednesday, May 31, 2023 at 11:00:58 AM UTC-7 Dima Pasechnik wrote:
>
> On Wed, May 31, 2023 at 6:23 PM Matthias Koeppe
> <matthia...@gmail.com> wrote:
> > As service for those who are missing the references: [...]
> >
> > - 5-year plan (appeared in https://groups.google.com/g/sage-devel/c/sVeu16vaEqo/m/D4pewORzAQAJ and previously in https://github.com/sagemath/sage/pull/35404#issuecomment-1505048255) = refers to a practice of the Soviet union introduced by Stalin and later by other countries in the Eastern Bloc. The first Soviet 5-year plan led to millions of deaths by famine. This reference is particularly offensive because both Dima and I grew up in the Eastern Bloc.
>
> Offensive? You seem to find this offensive now, but making similar is
> spirit remarks about my alledged lack of knowledge of English,
> or me being deeply Soviet in my mind, or I f**king don't know what, as in
> https://github.com/sagemath/sage/issues/32532#issuecomment-1418146524
> is OK for you?
> I quote:
>
> > Ah, this is a common confusion. gcc is a standard package - in this case the word is spelled "standard" but it's pronounced "base".
> > I think this complicated situation is due to the 1918 spelling reform.
>
> (Remark: there was a spelling reform of Russian 1918 in USSR, cf. wikipedia)
>
> By the way, it's from https://github.com/sagemath/sage/issues/32532
>
>
> I'm sorry to hear that you were offended by that, I had no idea. It definitely was not my intention.

The merit of the joke did not matter, what mattered was replacing a
technical discussion by a joke in
https://github.com/sagemath/sage/issues/32532 - that was what I found offensive.
And this sort of pattern repeated with minor variations (with jokes
often replaced by various bogus arguments) in a range of other
tickets, issues and PRs - no wonder I got fed up with it, eventually.

> To the contrary, I was referring to my (limited) knowledge of the Russian language and its development as a reminder of our friendly in-person interactions when you visited me in Berkeley and Davis --- which now seems ages ago.
>
> I'll now explain the joke:
> - "base" referred to the special status of some "standard" packages as in https://github.com/sagemath/sage/blob/develop/build/make/Makefile.in#L256 and some loose ends in the source code related to that, https://github.com/sagemath/sage/blob/develop/build/sage_bootstrap/package.py#L327
> - the 1918 spelling reform of Russian consolidated some vowels, rendering some entirely unrelated words to be spelt the same (I'm not sure whether also pronounced the same)
> - the phrase "the word is spelt '...' but it's pronounced '(something obviously unrelated)" is a reference to a popular Monty Python sketch that involves a character named Raymond Luxury-Yacht whose name is pronounced quite unrelated to this spelling.
>
>

> --
> 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/43165a7b-6687-42c2-a914-051ee93e45f6n%40googlegroups.com.

[G. M.-S.]

Hi all.

I would like to ask for a moratorium of at least 1 month on this discussion, as it is leading nowhere.  As a corollary, no changes on anything related to it for the time being.

I would also like to ask if anybody could enforce this moratorium.

And in addition I would like to take the occasion to thank everybody involved in SageMath, which is a wonderful project.

Repeating an evidence, all of you are important.

Best,

Guillermo

[David Roe]

I will delete any messages to this thread in the next week.  I encourage people who have not yet engaged to think about the issue and see if they have a compromise to suggest.

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

[Marc Culler]

On Tuesday, May 30, 2023 at 9:17:17 AM UTC-5 Dima Pasechnik wrote:

Well, have you notiiced that while casting his vote, Matthias wrote a
full screenful of questionable explanations of why he voted "no",

That is what always happens when people try to force a vote before there has been a discussion of sufficient depth to allow a consensus to form.  That has been understood for a long time.  Robert's Rules of Order were written in 1876.  Our great new technology  has made us forget useful things that we used to know.

- Marc

[Tobias Diez]

On Saturday, 3 June 2023 at 19:31:18 UTC+8 Marc Culler wrote:

That is what always happens when people try to force a vote before there has been a discussion of sufficient depth to allow a consensus to form. 

To clarify since this point came up before: The discussion about this topic started over two years ago in https://github.com/sagemath/sage/issues/30384, then this February continued on the sage mailing list (https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ) and in April in the PR https://github.com/sagemath/sage/pull/35403. However, only Matthias, Dima and me joined the discussion. Since we three couldn't come to a consensus, I opened the vote in order to get the input from the broader sage community (following advice from David and William).

[G. M.-S.]

For the benefit of all of us (including Dima, Matthias and Tobias), would it be possible to start afresh, without any reference whatsoever to these 3 linked discussions?

Also, would it be possible for David to act somehow as a "moderator"?

Best,

Guillermo

[Tobias Diez]

Any suggestions on how to move forward now? Should I simply open a new vote or are there still open questions or a need to discuss certain aspects of the proposal?

[David Roe]

Thanks for restarting the discussion Tobias.  From my perspective, there are several things that can move this conversation forward.

1. More clarity on how NEP-29 will be implemented in Sage.  In particular, that policy just guarantees a particular time frame during which Python will be supported, but doesn't describe what happens afterward.  Once the window is passed, is someone (who?) going to proactively update build scripts to prohibit the old version of python?  Or does it just grant permission for people to use features that are not available in the old Python, and merging such a PR will also involve updating the build requirements?

2. A wiki page. Currently, the arguments for and against this change are pretty scattered.  Tobias (and Dima), could you create a wiki page where pros and cons are summarized?  Once you do, I would suggest running it by Matthias, since a lot of the arguments against it have come from him.

3. A timeline.  I'm going to suggest three weeks for discussion, with voting starting July 18 and ending one week later on July 25 (anywhere on earth).  I know that there have been conversations on and off about this issue for a while, but I think having some time dedicated to focused discussion may help others feel like they have a full grasp of the issue.

4. Additional people getting involved in the conversation.  Tobias, Dima and Matthias all clearly feel quite strongly about this issue and have been involved in it for a while.  Other people can hopefully bring some more perspectives, suggesting compromises or giving additional perspectives.  In the end, we need other people to vote, so that Tobias, Dima and Matthias can get some resolution on this.

5. A moderator.  Several people asked me to moderate last time, and I'll do my best for this discussion.  I'll start with a few requests for everyone involved. 

 * First, I think multiple short, quick rebuttals are not a good idea in a heated email discussion.  We have three weeks.  Take the time to collect your thoughts and respond to the whole of an argument.  If appropriate, add things to the pros and cons on the wiki page.  Most of all, take the time to read what you've written and think about how it will be received by both the people you're arguing with and the thousands of people subscribed to sage-devel. 

 * Second, take a step back and think about what you can do to make this environment more welcoming and pleasant for everyone.  I know several people involved have said that the issues we're discussing, and the way we're discussing them, have lessened their desire to contribute to Sage, and I think that would be a tragedy.  All three of you are critical members of this community, and I don't want to lose you.  I'm not going to prescribe anything specific, but I think it would help if everyone can think about ways to show that you value the people involved, even if we have specific technical disagreements.

 * Third, while work goes forward on a summarizing wiki page, I'd like to hear suggestions from others about how to make the process better.  Feel free to email the list or write to me directly.

We made it through the github discussion, and we can make it through this.  Stay positive.

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/feaeb36f-129b-4c18-9789-6cc97c1556a9n%40googlegroups.com.

[Tobias Diez]

Thanks David for your suggestions!

I've now created a wiki page at https://github.com/sagemath/sage/wiki/NEP-29:-Python-version-strategy that on the one hand clarifies a few questions that were raised before and on the other hand summarizes the discussion we had so far. I tried to add all points raised as objectively as possible, but could have easily missed some arguments and misinterpreted others. So please have a look a the page and edit it as you see fit. I propose that major additions or changes to the wiki page are first discussed here on the mailing list so that we don't end in a edit war.

[Matthias Koeppe]

Thanks Tobias for creating this wiki page. 

I will edit it today so it presents more than 1 proposal on equal footing.

[Nils Bruin]

On Thursday, 6 July 2023 at 09:36:25 UTC-7 Tobias Diez wrote:

Thanks David for your suggestions!

I've now created a wiki page at https://github.com/sagemath/sage/wiki/NEP-29:-Python-version-strategy that on the one hand clarifies a few questions that were raised before and on the other hand summarizes the discussion we had so far. I tried to add all points raised as objectively as possible, but could have easily missed some arguments and misinterpreted others. So please have a look a the page and edit it as you see fit. I propose that major additions or changes to the wiki page are first discussed here on the mailing list so that we don't end in a edit war.

It looks to me that proposal 1 and proposal 2 in practice would probably end up with pretty much the same effect for most of the time, so the formulation is mainly important for edge cases and for conflict resolution.

It looks to me proposal 1 still doesn't make it *mandatory* to drop support outside of the NEP29-defined version window. It seems to me that it just defines when a support-drop PR becomes acceptable to merge, and that such a PR would only be issued once someone feels there's a benefit to its merge.

If that interpretation is right, it seems to me that the difference between proposal 1 and proposal 2 will only be relevant if there is a PR to drop a python version V (outside of the NEP29 window) and there is someone else who want to keep support for that version V. With proposal 2 we'd get a discussion of the relevant pros and cons. With proposal 1, there'd normally not be a discussion at this point: version V is fair game to be dropped. There could still be a discussion if someone claims there's an exceptional circumstance that warrants deviating from official policy, but that would have a much higher bar to clear.

From the perspective above, Proposal 1 seems more attractive to me than Proposal 2, since it avoids extra discussion with what seems a very reasonable default policy (the NEP 29 window seems wide enough to me). Would it be possible to highlight when Proposal 2 would be beneficial? One scenario I can think of is: "the NEP 29 window is sometimes to narrow" which I don't have evidence for.

 

[Matthias Koeppe]

On Thursday, July 6, 2023 at 2:25:12 PM UTC-7 Nils Bruin wrote:

On Thursday, 6 July 2023 at 09:36:25 UTC-7 Tobias Diez wrote:

Thanks David for your suggestions!

I've now created a wiki page at https://github.com/sagemath/sage/wiki/NEP-29:-Python-version-strategy that on the one hand clarifies a few questions that were raised before and on the other hand summarizes the discussion we had so far. I tried to add all points raised as objectively as possible, but could have easily missed some arguments and misinterpreted others. So please have a look a the page and edit it as you see fit. I propose that major additions or changes to the wiki page are first discussed here on the mailing list so that we don't end in a edit war.

It looks to me that proposal 1 and proposal 2 in practice would probably end up with pretty much the same effect for most of the time

I don't think so; I think there is an effective difference of about 6–9 months.

Just O(1), of course, but so are the release cadences of OS distributions and major packages.

[Matthias Koeppe]

I'm done with editing for today. There are still a number of major "TBD"s there; others are welcome to help with these.

Matthias

[Nils Bruin]

On Thursday, 6 July 2023 at 14:55:35 UTC-7 Matthias Koeppe wrote:

I don't think so; I think there is an effective difference of about 6–9 months.

Just O(1), of course, but so are the release cadences of OS distributions and major packages.

In NEP 29 I see a 42 month window; in Proposal 2 I also see a 42 month window. Where does the 6-9 month difference come from?

I see NEP 29 uses the *anticipated* release date; probably so that as soon as a release is planned, it will be clear which python versions will be supported by it and that delay won't mean pulling python versions from the supported list. [For both Proposal 1 and Proposal 2 it may be a good idea to also be explicit about the way the 42 month window is pegged]

Do you anticipate Proposal 1 and 2 to differ in what they use as indicator date for the 42 month window?

The main difference between the wordings of the two proposals seems to be: "the SageMath project clarifies that it is invalid for a developer to demand that we drop support immediately at the stated time". So I think that means Proposal 2 explicitly advocates for discussion of each PR that drops support, rather than the default date-based accept that Proposal 1 advocates. Can you elaborate on the advantages of that? Do you anticipate that the 42 month window is too short? Particularly with how easy it is nowadays with conda to install fresh python versions as a user, is it onerous for people to get a new python when they upgrade sage?

 

[Matthias Koeppe]

On Thursday, July 6, 2023 at 4:51:57 PM UTC-7 Nils Bruin wrote:

On Thursday, 6 July 2023 at 14:55:35 UTC-7 Matthias Koeppe wrote:

I don't think so; I think there is an effective difference of about 6–9 months.

Just O(1), of course, but so are the release cadences of OS distributions and major packages.

In NEP 29 I see a 42 month window; in Proposal 2 I also see a 42 month window. Where does the 6-9 month difference come from? [...]

It's just the difference between the point in time when NEP 29 *allows* us to to drop a version and the point in time when we would *drop* the version following our current practice. (See https://github.com/sagemath/sage/wiki/NEP-29:-Python-version-strategy#schedule-with-comparison-to-nep-29).

The main difference between the wordings of the two proposals seems to be: "the SageMath project clarifies that it is invalid for a developer to demand that we drop support immediately at the stated time". So I think that means Proposal 2 explicitly advocates for discussion of each PR that drops support,

Proposal 2 simply describes the current practice. PR author proposes and builds the case for the change, and a normal discussion take place on the PR.

Proposal 1 includes a reversal of burden of proof. Right when NEP 29 allows us to drop a version, someone can (and will) prepare the (trivial) PR and demand that it be merged immediately. The wording of proposal 1 reserves deviating from this to "exceptional cases".

Can you elaborate on the advantages of [Proposal 2]

Sure, I've planned to be adding this to the wiki page in my next writing session, before the start of the coming week.

Matthias

[Kwankyu Lee]

Proposal 2 simply describes the current practice. PR author proposes and builds the case for the change, and a normal discussion take place on the PR.

I want to see, in the wiki page, a summary of what are (or should be) considered to "build the case", which could be used as an agenda for a PR for the next drop of old python.   

[Matthias Koeppe]

On Thursday, July 6, 2023 at 6:01:02 PM UTC-7 Kwankyu Lee wrote:

Proposal 2 simply describes the current practice. PR author proposes and builds the case for the change, and a normal discussion take place on the PR.

I want to see, in the wiki page, a summary of what are (or should be) considered to "build the case", which could be used as an agenda for a PR for the next drop of old python.   

Good idea, I'll add that.

[Tobias Diez]

On Thursday, 6 July 2023 at 23:25:12 UTC+2 Nils Bruin wrote:

It looks to me proposal 1 still doesn't make it *mandatory* to drop support outside of the NEP29-defined version window. It seems to me that it just defines when a support-drop PR becomes acceptable to merge, and that such a PR would only be issued once someone feels there's a benefit to its merge.

If that interpretation is right, it seems to me that the difference between proposal 1 and proposal 2 will only be relevant if there is a PR to drop a python version V (outside of the NEP29 window) and there is someone else who want to keep support for that version V. With proposal 2 we'd get a discussion of the relevant pros and cons. With proposal 1, there'd normally not be a discussion at this point: version V is fair game to be dropped. There could still be a discussion if someone claims there's an exceptional circumstance that warrants deviating from official policy, but that would have a much higher bar to clear.

Yes, this interpretation is what I had in mind.

 

From the perspective above, Proposal 1 seems more attractive to me than Proposal 2, since it avoids extra discussion with what seems a very reasonable default policy (the NEP 29 window seems wide enough to me).

For me, this is the main advantage of having a policy about the drop schedule. We can now have a dedicated conversation to thoroughly explore the pros and cons, to consider various perspectives, gather feedback, and make an informed decision. Once a policy has been established and agreed upon, it provides a clear framework that eliminates the need for repetitive discussions and debates about dropping specific policies in every PR again.