I've set the first one to needs work since it changes some versions in the
pyproject.toml (which specifies the depenendies of sagelib). Since the PR
doesn't include any other changes in sagelib, I don't think these stricter
version constraints for sagelib make sense and should be reverted.
On
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
pecific 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 discussi
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
>
> On Sun, 4 Jun 2023 at 17:37, Tobias Diez wr
On Wednesday, 14 June 2023 at 05:37:15 UTC+8 Matthias Koeppe wrote:
- Some # optional annotations reduce the barrier for contributors, by
clearly signaling to developers "it's OK and definitely not your fault if
you don't understand this doctest".
To be honest, this sounds like wishful thinki
On Wednesday, 14 June 2023 at 05:03:21 UTC+8 Matthias Koeppe wrote:
More specifically, when users of a modularized distribution make their
first steps to contributing to it, that's already difficult; and we do not
want to have to tell them "if you want to make this contribution, you first
have
On Wednesday, 14 June 2023 at 02:36:16 UTC+8 Matthias Koeppe wrote:
- Modularized distributions must be testable separately!
And why is this a desirable goal?
Integration tests almost by definition are testing multiple modules/units
and thus don't fit into this scheme.
Admittedly, the only
rote:
> On Tue, Jun 13, 2023 at 4:14 PM Tobias Diez wrote:
> >
> > What about a completely different approach: Instead of annotating the
> doctests, simply ignore test blocks that fail due to a thrown import error
> (or missing feature error) of a package that is not
What about a completely different approach: Instead of annotating the
doctests, simply ignore test blocks that fail due to a thrown import error
(or missing feature error) of a package that is not installed in the
modularized test environment? That might hide some edge cases, but would in
total
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 o
I used github codespaces for sage development for some until since I only
had a weak laptop with me. It worked quite well, actually better than
gitpod (mainly due to better vscode integration). But you can easily try it
out yourself. Just go to
https://github.com/codespaces/new?hide_repo_select
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
I can also point at the already existing possibility to use Conda's Python
packages on a Conda-based install.
This mode of installation (
https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental)
bypasses the Sage dis
> a) Sage has a dual role as a library ("project") and as a distribution.
NEP 29 was designed for projects, and not for software distributions.
What problems do you see that come from sage having aspects of a software
distribution?
"Sage-the-distribution" allows us to reduce the inconvenien
-distribution goes, we should tie the support window to
> popular distros. Ideally by liberally calling "conda install python"
> whenever the distro python is too old.
>
> Its unclear to me if this or the vote thread is about the library code or
> the distribution...
>
&
posed-scientific-python-ecosystem-support-period)
On Saturday, 27 May 2023 at 00:56:12 UTC+8 Tobias Diez wrote:
> Here is the PR that introduced NEP 29:
> https://github.com/numpy/numpy/pull/14086. The main discussion happened
> in person at scipy 2019 and in webcalls. But a lot of the po
Python, we often have to wait until all or
> most of our dependencies provide support for that new version. For example,
> some projects are actively working on support for the Python 3.12 release
> expected this early Fall; but for us, this is not actionable because we
> have to wait fo
Dear Sage developers,
the NumPy enhancement proposal 29: "Recommend Python and Numpy version
support as a community policy standard" (available at
https://numpy.org/neps/nep-0029-deprecation_policy.html) specifies when
it's okay to drop support for old Python version.
Namely, a release should
The branch protection rules don't allow to make an exception for a single
person (the release manager). What can be configured though is that all
pushes to develop (from everybody, including admins) have to go through a
PR. This would mean that the merge and release commits also has to go
throu
Hi all,
I propose to follow the NumPy enhancement proposal 29: "Recommend Python
and Numpy version support as a community policy standard" available at:
https://numpy.org/neps/nep-0029-deprecation_policy.html
In essence it specifies when it's okay to drop support for old Python
version. Name
Github provides a free teams account for (registered) non-profit orgs.
There is not a huge difference between the free and the teams account (see
https://github.com/pricing), especially if we don't use private repos.
However, prebuilds for Github Codespaces can only be enabled for orgs on
the T
What about moving this sage-devel mailing list to github discussions? I
think this is orthogonal to handling the user support via gh discussions.
Btw, you one can customize the notifications to only include/exclude
discussions:
https://docs.github.com/en/account-and-profile/managing-subscriptio
You need to use upstream (the official sage repo) instead of origin (your
fork) to fetch the PR: git fetch upstream
pull/PULL-REQUEST-ID/head:LOCAL-BRANCH-NAME see
https://github.com/sagemath/trac-to-github/blob/master/docs/Migration-Trac-to-Github.md#for-reviewing-a-change
If you don't have an
Wouldn't it be easier to automate (and more respectful to the privacy
concerns of contributors) to simply link to the github handle/profile?
On Wednesday, 8 February 2023 at 04:51:30 UTC+8 Matthias Koeppe wrote:
> We have collected these mappings in
> https://github.com/sagemath/website/blob/ma
One can use the branch protection rule to restrict who can merge PRs into
the protected branch:
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#restrict-who-can-push-to-matching-branches
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/sag
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
Github as their own open archive program
(https://archiveprogram.github.com/) and works together with known software
/ archive websites. In particular, the code itself is archived via the
EU-funded Software Heritage foundation and issue/PR metadata for all public
repos are in GHTorrent / GHArch
Okay, fair enough! Then it's a bit more work to get tickets into PRs (for
devs) but maybe its a good idea to start with a clean slate.
On Tuesday, 27 September 2022 at 22:31:57 UTC+2 dim...@gmail.com wrote:
>
>
> On Tue, 27 Sep 2022, 21:12 Tobias Diez, wrote:
>
>> J
to it)
On Tuesday, 27 September 2022 at 15:29:35 UTC+2 dim...@gmail.com wrote:
>
>
> On Tue, 27 Sep 2022, 14:08 Tobias Diez, wrote:
>
>> Yes, the target repo of these PRs will be the (new) sagemath/sage, but
>> the source will be sagemath/sagetrac-mirror, right?
>
>
022 at 11:29 AM Tobias Diez wrote:
> >
> > One more question: The current plan is to use the sagetrac-mirror repo
> as the base for creating PRs but also to archived it. However, if I'm not
> mistaken, that makes all branches in sagetrac-mirror readonly and thus one
&g
One more question: The current plan is to use the sagetrac-mirror repo as
the base for creating PRs but also to archived it. However, if I'm not
mistaken, that makes all branches in sagetrac-mirror readonly and thus one
cannot continue working on existing PRs by pushing to the corresponding
bra
2. Convert all tickets to Issues in a new repo. (This preserves the ticket
> numbers as Issue numbers.)
>
Would it make sense to convert tickets with branches directly to
pull-requests? Since most of them probably already contain quite a bit of
discussion about the implementation, which you w
+1 for Github
On Thursday, 22 September 2022 at 14:19:57 UTC+2 Jonathan wrote:
> +1 for Github
>
> On Thursday, September 22, 2022 at 5:06:02 AM UTC-5 antoine@gmail.com
> wrote:
>
>> +1 for Github
>>
>> Le jeudi 22 septembre 2022 à 11:38:17 UTC+2, chris wuthrich a écrit :
>>
>>>
>>> 0(No
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"; shou
Smaller suggestions can also be made through the github web interface as
part of the pullrequest review, see
https://egghead.io/lessons/github-add-suggestions-in-a-github-pr-review and
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/in
Yes, having "issues" and "pull requests" separated is a huge change to the
way things are handled on trac. Naturally there are advantages and
disadvantages for both approaches. In the github world, issues are treated
more as a list of open tasks and are usually more user-focused. For
example, a
Matthias, people have their own workflows that evolved around using trac
for a long time. It is only natural that there are now questions of how
these workflows will look like when using github. We should give space to
such questions following the spirit of "there are no stupid questions".
Espe
It does read very nicely, good job!
On Monday, 12 September 2022 at 22:10:30 UTC+2 Matthias Koeppe wrote:
> On Monday, September 12, 2022 at 12:07:13 AM UTC-7 tobias...@gmail.com
> wrote:
>
>> If you first cloned the main repo and then decide to fork, the common
>> approach is to rename the ori
As much as I agree with this sentiment and personally dislike the naming
"origin/upstream" as well, it is the most widespread naming convention in
the fork model. See e.g
https://docs.scipy.org/doc/scipy/dev/gitwash/development_setup.html I think
its a good idea to stick to the established conv
On Sunday, 11 September 2022 at 13:56:11 UTC+2 seb@gmail.com wrote:
> I think an explicit description of what will replace the states of a
> ticket (for example positive review) is still missing.
>
PR reviews can either request changes (= "needs work") or approve
(="positive review"). I've
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 do
VS code cannot debug python code that is executed by a shell script. You
have to execute python code directly in order to debug it. My strategy
usually is to create a new (temporary) python file that contains the code I
want to debug (or calls the method I want to debug), and then use the
pytho
I've now added a branch protection rule for the github mirror, so that one
can no longer push directly to it (so it's a true mirror now). The sageb0t
user got an exemption so the sync from trac to the github mirror should
still work (I've tested it for with a few commits).
Now if someone tries
>From the logs:
error: Command "gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv
-O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g
-fwrapv -O2 -g -O2 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I./sage/cpython
-I/mnt/g/Maths/sage-9.5/clone/local/var/lib/sage/venv-pyth
I agree that linuxbrew might not be most optimal choice for sage. It is
currently installed by gitpod automatically in their full-image that we
use. But they are also in the process to restructure their images at
https://github.com/gitpod-io/workspace-images/tree/master. For example, the
new wo
Hi everyone,
as you probably have already seen, there are a few new status badges in the
trac ticket display.
We have now:
1. Linter that checks that the code of the current branch adheres to the
style guidelines. In order to see details when it fails, you can click on
it and then select the mo
Thanks for the explanation, this makes a few things clearer to me!
The "in-place" builds sounds very promising indeed. I would like to help in
this direction, but feel like I don't have the knowledge to contribute
directly. However, if there is something to try-out / play around with,
please l
\
fi
real4m25.825s
user0m24.257s
sys 0m36.241s
tobias@DESKTOP-OMSMBL2:/mnt/d/Programming/Projects/sage$
On Sunday, May 31, 2020 at 3:07:40 PM UTC+2, Dima Pasechnik wrote:
>
> On Sun, May 31, 2020 at 1:59 PM Eric Gourgoulhon > wrote:
> >
> > Hi Tobias,
>
Hi everybody,
(disclaimer: everything I say comes from a few days of playing around with
sage's code - so I might make some wrong statements that are obvious to
more experienced sage devs)
currently `./sage -b` rebuilds the python interpreter part of sage (i.e.
special syntax support etc) as w
50 matches
Mail list logo
