[sage-devel] pull requests for migrated issues

2023-02-06 Thread 'Lorenz Panny' via sage-devel
Sorry if this is answered somewhere in the new documentation, I couldn't find it: What is the intended procedure for migrated issues which were in "needs review" state and already had a branch? Am I to push the branch to my own fork and create a fresh pull request for each such issue? -- You re

Re: [sage-devel] compiling sage without documentation

2023-03-16 Thread 'Lorenz Panny' via sage-devel
I usually just run "make build" instead of "make" to skip building the documentation (with unmodified ./configure arguments). Does that satisfy your needs? Best, Lorenz On Thu, 16 Mar 2023 11:00:08 +0100, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > Dear all, > > I would like to co

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

2024-01-10 Thread &#x27;Lorenz Panny&#x27; via sage-devel
How about .linearize()? (I think this method should also optionally take a list of monomials as an argument, since there are situations in which users would like to force their own ordering. Returning the same monomial vector again would then of course be redundant, so in that case the method co

[sage-devel] meta tickets

2024-01-10 Thread &#x27;Lorenz Panny&#x27; via sage-devel
Back in the days of trac, we sometimes had meta tickets that anyone could edit, for things such as wishlists or keeping track of larger projects. Some of these meta tickets were turned into GitHub issues, but now they are no longer editable by anyone except the original author (or so it seems). I

[sage-devel] tickets from Sage Days: please review

2024-01-20 Thread &#x27;Lorenz Panny&#x27; via sage-devel
Sage Days 123 in Leuven ended yesterday and quite a few pull requests have come out of it already, most of them from new contributors. 🎉 I would like to encourage potential reviewers to have a look at them sooner rather than later in order to hopefully keep some of the fresh momentum alive. (Plea