Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[Jeremy Tan]

https://trac.sagemath.org/ticket/34536

There, Luschny!

On why I initially only changed B_1 = +½, I have a rebuttable demand of my
code: *it must be as beautiful as the maths it implements*. Having
bernoulli_gen() (your generalised Bernoulli function as implemented in the
SageMath ticket) alongside an integer-only bernoulli() is not pretty to me,
and especially not pretty when they return inconsistent values at 1.

Hence my first idea was to overload bernoulli() like I did with SymPy, but
seeing as that was not very feasible, my second idea was to simply change
B_1 = +½. Now that you prodded me into finding hurwitz_zeta() at top-level,
I have the new ticket *only* implementing bernoulli_gen().

Jeremy Tan / Parcly Taxel

On Thu, 15 Sept 2022, 02:01 Peter Luschny,  wrote:

> tl;dr, 80 lines, sorry.
>
> I think there is a better alternative than changing the current
> implementation of the Bernoulli numbers.
>
> Fredrik: "The sign convention for B_1 is fairly arbitrary, ..."
>
> Calling the question a 'convention' sets a wrong framing from
> the start. Conventions are treated differently than bugs.
> And this is a bug. Setting B- leads to inconsistency in several
> identities, which I have described on my known web-page.
>
> Fredrik, honestly, do you really think Knuth rewrites TAOCP
> and CM just to change an arbitrary sign convention? Knuth
> expressly considers it a mistake.
>
> As long as the discussion is viewed as one about conventions,
> it is uninteresting and does not improve our understanding of
> the situation. People who believe this can equally well flip
> a coin when in doubt.
>
> Best leave the whole discussion behind, the question of + or -,
> the question of convention or bug, the question of decision
> or compromise, or what people on Twitter think (Fredrik asked :))
> All answers to such questions must be profoundly unsatisfactory.
>
> The matter should be solved mathematically in a way Euler
> would have liked, without resorting to this absurd fixation
> on a single value.
>
> And by that, I mean to define a suitable complex function,
> call it the 'Bernoulli function', and then say: The 'Bernoulli
> numbers' are the values of this function on the non-negative integers.
>
> Everyone knows a possible way to do this: B(z) = -z*zeta(1-z).
> Of course, you could add a sin or cos factor to it (Fredrik
> mentioned that, Knuth too, by the way), but why should you do
> that? Occam's razor speaks against it. Maximum simplicity has
> always belonged to the beauty criteria in mathematics.
>
> Similar approaches have already been done; Helmut Hasse, for
> example, has constructed the corresponding function without
> recourse to the zeta function. And there are also other
> representations without reference to the zeta function.
>
> Another pleasing possibility is via the Jensen-Johansson-Blagouchine
> formulas, first given by Jensen and first proved by Johansson
> and Blagouchine ("Computing Stieltjes constants using complex
> integration").
>
> These formulas are also the starting point in my arXiv paper.
> There I try to show that this function is also essential in
> other contexts in the theory of special numbers and offers
> some technical advantages.
>
> * My suggestion: Offer this function in Sage. This may not mean
> much more than a three-line wrapper around the zeta function.
> Then the current code does not have to be changed, no deprecation
> warnings, no keywords for alternatives are required.
>
> The decision is then solely up to the user whether he wants
> to continue the current usage and use bernoulli(n) or find
> pleasure in bernoulli_function(n).
>
> Fredrik's fear that new "ambiguity and inconsistency" could
> creep in is then unfounded: The names and the definitions are
> too different; here polynomials, there a zeta-like function,
> both with different applications.
>
> If you want to describe this approach in a highfalutin way,
> it is Grothendieck-ish. It does not answer the question which
> of the two values is the 'correct' one; it shows how this problem
> disappears when put into the proper conceptual framework.
>
> This approach also makes sense in all the other cases that
> Fredrik has to decide. With it, the burden of making a sensible
> decision is turned into the freedom for the user to explore
> a fascinating function.
>
>  --
>  Peter
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/G4sbKoibXK4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/19d2d0c8-556b-4bbf-a9d1-e87e7e8ed4c9n%40googlegroups.com
> 
> .
>

-- 
You 

Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[Jeremy Tan]

Thank you for coming, Luschny.

I not only wholeheartedly believe B_1 = +½ and that there is no convention
about it, but also that I believe in the reality and usefulness of the
Bernoulli, Euler and other functions you defined in your 2020 paper.

When I implemented those functions in SymPy there was already a base –
two-argument bernoulli() and euler() with polynomial support were there, as
well as genocchi(). So I could easily generalise those functions into yours.

On the other hand, until writing this reply I did not know that SageMath
exposed a hurwitz_zeta() function by default from which I can define the
generalised Bernoulli function. Hold on; I'll have a new ticket ready.

Jeremy Tan / Parcly Taxel

On Thu, 15 Sept 2022, 02:01 Peter Luschny,  wrote:

> tl;dr, 80 lines, sorry.
>
> I think there is a better alternative than changing the current
> implementation of the Bernoulli numbers.
>
> Fredrik: "The sign convention for B_1 is fairly arbitrary, ..."
>
> Calling the question a 'convention' sets a wrong framing from
> the start. Conventions are treated differently than bugs.
> And this is a bug. Setting B- leads to inconsistency in several
> identities, which I have described on my known web-page.
>
> Fredrik, honestly, do you really think Knuth rewrites TAOCP
> and CM just to change an arbitrary sign convention? Knuth
> expressly considers it a mistake.
>
> As long as the discussion is viewed as one about conventions,
> it is uninteresting and does not improve our understanding of
> the situation. People who believe this can equally well flip
> a coin when in doubt.
>
> Best leave the whole discussion behind, the question of + or -,
> the question of convention or bug, the question of decision
> or compromise, or what people on Twitter think (Fredrik asked :))
> All answers to such questions must be profoundly unsatisfactory.
>
> The matter should be solved mathematically in a way Euler
> would have liked, without resorting to this absurd fixation
> on a single value.
>
> And by that, I mean to define a suitable complex function,
> call it the 'Bernoulli function', and then say: The 'Bernoulli
> numbers' are the values of this function on the non-negative integers.
>
> Everyone knows a possible way to do this: B(z) = -z*zeta(1-z).
> Of course, you could add a sin or cos factor to it (Fredrik
> mentioned that, Knuth too, by the way), but why should you do
> that? Occam's razor speaks against it. Maximum simplicity has
> always belonged to the beauty criteria in mathematics.
>
> Similar approaches have already been done; Helmut Hasse, for
> example, has constructed the corresponding function without
> recourse to the zeta function. And there are also other
> representations without reference to the zeta function.
>
> Another pleasing possibility is via the Jensen-Johansson-Blagouchine
> formulas, first given by Jensen and first proved by Johansson
> and Blagouchine ("Computing Stieltjes constants using complex
> integration").
>
> These formulas are also the starting point in my arXiv paper.
> There I try to show that this function is also essential in
> other contexts in the theory of special numbers and offers
> some technical advantages.
>
> * My suggestion: Offer this function in Sage. This may not mean
> much more than a three-line wrapper around the zeta function.
> Then the current code does not have to be changed, no deprecation
> warnings, no keywords for alternatives are required.
>
> The decision is then solely up to the user whether he wants
> to continue the current usage and use bernoulli(n) or find
> pleasure in bernoulli_function(n).
>
> Fredrik's fear that new "ambiguity and inconsistency" could
> creep in is then unfounded: The names and the definitions are
> too different; here polynomials, there a zeta-like function,
> both with different applications.
>
> If you want to describe this approach in a highfalutin way,
> it is Grothendieck-ish. It does not answer the question which
> of the two values is the 'correct' one; it shows how this problem
> disappears when put into the proper conceptual framework.
>
> This approach also makes sense in all the other cases that
> Fredrik has to decide. With it, the burden of making a sensible
> decision is turned into the freedom for the user to explore
> a fascinating function.
>
>  --
>  Peter
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/G4sbKoibXK4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/19d2d0c8-556b-4bbf-a9d1-e87e7e8ed4c9n%40googlegroups.com
> 
> .
>

-- 
You received this 

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

[Matthias Koeppe]

On Wednesday, September 14, 2022 at 1:50:43 AM UTC-7 tobias...@gmail.com 
wrote:

> 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/incorporating-feedback-in-your-pull-request
>

 Thanks, I've added this 
to https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b

-- 
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/c1ba42b4-0b67-42b4-939e-5d6621b474ban%40googlegroups.com.

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

[Matthias Koeppe]

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/1dedc001-b342-4795-ad0b-0d8f187f1a24n%40googlegroups.com.

Re: [sage-devel] Invitation: Weekly Sage developer calls on Zoom, starting this Thursday!

[François Bissey]

I am in the middle of picking a kid from school at that time so I won't 
be there for that one tomorrow. Filled my bit in the pool.


On 15/09/22 06:36, Matthias Koeppe wrote:

Friday afternoon, 3:15pm Auckland (New Zealand)


François

--
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/43fa7b53-0ebf-fb45-20da-54fd20e2edfa%40gmail.com.

[sage-devel] Re: Invitation: Weekly Sage developer calls on Zoom, starting this Thursday!

[Matthias Koeppe]

On Wednesday, September 14, 2022 at 11:36:19 AM UTC-7 Matthias Koeppe wrote:

> We would hope that there is enough interest to make it a weekly meeting, 
> possibly alternating between these two times so that we can include a 
> convenient time for everyone in all timezones.
> In order to find the best times that work well for most who are interested 
> in participating, please fill out this poll for the regular times to use 
> from next week on. http://whenisgood.net/2kbimt4 
> 
>
>
I've updated the poll to include a time zone selection. Sorry for missing 
this when I posted 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/738bd980-a6af-46c5-b611-8ec411dab883n%40googlegroups.com.

[sage-devel] Re: Invitation: Weekly Sage developer calls on Zoom, starting this Thursday!

[David Ayotte]

I would be interested in participating. However my thursdays are usually 
busy (every two weeks). I'll definitely attend if it fits my schedule. I'm 
in EDT, UTC-4 timezone.

Best,

David A.

Le mercredi 14 septembre 2022 à 14:36:19 UTC-4, Matthias Koeppe a écrit :

> Dear all,
> William, Dima, and I would like to invite all of you to join a 30-minute 
> Sage developer call on Zoom. The purpose is: Short announcements/demos, 
> socializing, brief discussions, having coffee together. 
> This sort of weekly meeting has become pretty standard in big successful 
> open-source
> software projects, e.g., Kubernetes, Jupyter groups, etc. 
>
> We'll have the first two such calls this Thursday/Friday:
>
> Call 1:
> Thursday morning, 8:15am San Francisco
> Thursday morning, 11:15am New York
> Thursday afternoon, 17:15 Paris
> https://ucdavis.zoom.us/j/92371662861?pwd=TDZKR0lKb2xzTGhiM0l3cnFmaGRadz09
>
> Call 2:
> Thursday evening, 8:15pm Oakland (California)
> Friday afternoon, 3:15pm Auckland (New Zealand)
> Friday noon, 12:15 Tokyo
> https://ucdavis.zoom.us/j/93145702271?pwd=Ly92MkhrV3ZrQzF1TUhzOFdKWnlUUT09
>
> We would hope that there is enough interest to make it a weekly meeting, 
> possibly alternating between these two times so that we can include a 
> convenient time for everyone in all timezones.
> In order to find the best times that work well for most who are interested 
> in participating, please fill out this poll for the regular times to use 
> from next week on. http://whenisgood.net/2kbimt4 
> 
>
> Best,
> Matthias, Dima, William
>
>

-- 
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/f70695e7-d363-4fde-97d0-b87e2fbf1628n%40googlegroups.com.

[sage-devel] Invitation: Weekly Sage developer calls on Zoom, starting this Thursday!

[Matthias Koeppe]

Dear all,
William, Dima, and I would like to invite all of you to join a 30-minute 
Sage developer call on Zoom. The purpose is: Short announcements/demos, 
socializing, brief discussions, having coffee together. 
This sort of weekly meeting has become pretty standard in big successful 
open-source
software projects, e.g., Kubernetes, Jupyter groups, etc. 

We'll have the first two such calls this Thursday/Friday:

Call 1:
Thursday morning, 8:15am San Francisco
Thursday morning, 11:15am New York
Thursday afternoon, 17:15 Paris
https://ucdavis.zoom.us/j/92371662861?pwd=TDZKR0lKb2xzTGhiM0l3cnFmaGRadz09

Call 2:
Thursday evening, 8:15pm Oakland (California)
Friday afternoon, 3:15pm Auckland (New Zealand)
Friday noon, 12:15 Tokyo
https://ucdavis.zoom.us/j/93145702271?pwd=Ly92MkhrV3ZrQzF1TUhzOFdKWnlUUT09

We would hope that there is enough interest to make it a weekly meeting, 
possibly alternating between these two times so that we can include a 
convenient time for everyone in all timezones.
In order to find the best times that work well for most who are interested 
in participating, please fill out this poll for the regular times to use 
from next week on. http://whenisgood.net/2kbimt4 


Best,
Matthias, Dima, William

-- 
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/6db43fef-b0ce-4f3e-9621-519382e53b86n%40googlegroups.com.

Re: [sage-devel] m4ri fails on m2 MacBook air

[Ben Salisbury]

I could have swore that I did that command (at least once!).  Those threads 
above also suggest Xcode CLT needs to be > version 13, which I have.

Nevertheless, I ran through the whole process from start to finish again, 
and this time it worked!

-- 
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/71dcc609-7eae-48e2-93fa-eb2123754bf8n%40googlegroups.com.

[sage-devel] Re: On changing Bernoulli(1) to +½

[Peter Luschny]

tl;dr, 80 lines, sorry.

I think there is a better alternative than changing the current 
implementation of the Bernoulli numbers.

Fredrik: "The sign convention for B_1 is fairly arbitrary, ..."

Calling the question a 'convention' sets a wrong framing from 
the start. Conventions are treated differently than bugs. 
And this is a bug. Setting B- leads to inconsistency in several
identities, which I have described on my known web-page.

Fredrik, honestly, do you really think Knuth rewrites TAOCP 
and CM just to change an arbitrary sign convention? Knuth 
expressly considers it a mistake.

As long as the discussion is viewed as one about conventions, 
it is uninteresting and does not improve our understanding of
the situation. People who believe this can equally well flip
a coin when in doubt.

Best leave the whole discussion behind, the question of + or -, 
the question of convention or bug, the question of decision 
or compromise, or what people on Twitter think (Fredrik asked :)) 
All answers to such questions must be profoundly unsatisfactory.

The matter should be solved mathematically in a way Euler 
would have liked, without resorting to this absurd fixation
on a single value.

And by that, I mean to define a suitable complex function, 
call it the 'Bernoulli function', and then say: The 'Bernoulli 
numbers' are the values of this function on the non-negative integers.

Everyone knows a possible way to do this: B(z) = -z*zeta(1-z).
Of course, you could add a sin or cos factor to it (Fredrik 
mentioned that, Knuth too, by the way), but why should you do
that? Occam's razor speaks against it. Maximum simplicity has
always belonged to the beauty criteria in mathematics.

Similar approaches have already been done; Helmut Hasse, for 
example, has constructed the corresponding function without 
recourse to the zeta function. And there are also other 
representations without reference to the zeta function.

Another pleasing possibility is via the Jensen-Johansson-Blagouchine
formulas, first given by Jensen and first proved by Johansson 
and Blagouchine ("Computing Stieltjes constants using complex 
integration").

These formulas are also the starting point in my arXiv paper. 
There I try to show that this function is also essential in 
other contexts in the theory of special numbers and offers 
some technical advantages. 

* My suggestion: Offer this function in Sage. This may not mean
much more than a three-line wrapper around the zeta function. 
Then the current code does not have to be changed, no deprecation
warnings, no keywords for alternatives are required.

The decision is then solely up to the user whether he wants 
to continue the current usage and use bernoulli(n) or find 
pleasure in bernoulli_function(n).

Fredrik's fear that new "ambiguity and inconsistency" could 
creep in is then unfounded: The names and the definitions are 
too different; here polynomials, there a zeta-like function, 
both with different applications.

If you want to describe this approach in a highfalutin way, 
it is Grothendieck-ish. It does not answer the question which
of the two values is the 'correct' one; it shows how this problem
disappears when put into the proper conceptual framework.

This approach also makes sense in all the other cases that 
Fredrik has to decide. With it, the burden of making a sensible
decision is turned into the freedom for the user to explore 
a fascinating function.

 --
 Peter
 

-- 
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/19d2d0c8-556b-4bbf-a9d1-e87e7e8ed4c9n%40googlegroups.com.

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

[Matthias Koeppe]

On Wednesday, September 14, 2022 at 10:10:47 AM UTC-7 john.c...@gmail.com 
wrote:

> GH issues can also be used as "metatickets" on trac, with a checklist of 
> things to do which can be checked off as they are dealt with by various 
> PRs.  
>

Thanks, I've added this 
to https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b 

-- 
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/daaa36b2-b5e8-4a88-a07d-b8b9f63ef796n%40googlegroups.com.

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

[John Cremona]

GH issues can also be used as "metatickets" on trac, with a checklist of
things to do which can be checked off as they are dealt with by various
PRs.   We often do this with the LMFDB whose code development is done on GH
via issues and PRs as described by others here.  We have fewer developers
of course, and a few people (more than one but we'll under 10) who can
merge PRs into the develop branch once all the unit tests etc pass.

On Wed, 14 Sept 2022, 09:58 Tobias Diez,  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/2b08b01b-6220-4efd-8dfa-06f47a95868dn%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/CAD0p0K71NMX1J6NT9Rivh96fvbF%2B2YjxkyZ5YC9rrVRGGRBZXA%40mail.gmail.com.

Re: [sage-devel] m4ri fails on m2 MacBook air

[Dima Pasechnik]

Have you forgotten to

source .homebrew-build-env

 ?

On Wed, 14 Sep 2022, 15:10 Dima Pasechnik,  wrote:

> this
>
> https://bitbucket.org/malb/m4rie/issues/23/trying-to-compile-on-apple-m1
>
> and trac tickets mentioned there might be related.
>
>
> On Wed, 14 Sep 2022, 14:51 Ben Salisbury,  wrote:
>
>> I'm trying to build from source on a MacBook Air with the new m2 chip,
>> and the build fails at m4ri.  I've tried to install all the required
>> dependencies from brew (but maybe I've messed that up).  Any suggestions?
>>
>> --
>> 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/d7aca620-c559-4748-8192-89f819926cf1n%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/CAAWYfq2LJstxSrL6DUMxUwjMV2y_M2-8OnrWKfdd3HCkSq%2BJeg%40mail.gmail.com.

Re: [sage-devel] m4ri fails on m2 MacBook air

[Dima Pasechnik]

this

https://bitbucket.org/malb/m4rie/issues/23/trying-to-compile-on-apple-m1

and trac tickets mentioned there might be related.


On Wed, 14 Sep 2022, 14:51 Ben Salisbury,  wrote:

> I'm trying to build from source on a MacBook Air with the new m2 chip, and
> the build fails at m4ri.  I've tried to install all the required
> dependencies from brew (but maybe I've messed that up).  Any suggestions?
>
> --
> 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/d7aca620-c559-4748-8192-89f819926cf1n%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/CAAWYfq3r05Hy34SNVLbYdQ98qj57bvGtmKSVftamhuGpf1pFTw%40mail.gmail.com.

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

[Tobias Diez]

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/2b08b01b-6220-4efd-8dfa-06f47a95868dn%40googlegroups.com.

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

[Tobias Diez]

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/incorporating-feedback-in-your-pull-request

On Wednesday, 14 September 2022 at 04:15:10 UTC+2 Nils Bruin wrote:

> On Tuesday, 13 September 2022 at 14:04:24 UTC-7 dim...@gmail.com wrote:
>
>>
>>
>> On Tue, 13 Sep 2022, 21:56 Nils Bruin,  wrote:
>>
>>> I'd actually be interested in knowing what the substitute for "git trac 
>>> checkout ..." is. Because with trac, all ticket branches are present in the 
>>> "trac" repository, you can pull anything from there. If I have to 
>>> merge/pull from developer branch, do I need to add another remote to my 
>>> local sage git repository? That sounds very laborious. Particularly for how 
>>> to keep it up-to-date.
>>>
>>
>> No, you don't need to add the remote of the author of the PR, because the 
>> PR is a branch in the main repo.
>>
>> git-trac's functionality is provided by cli, a command line tool ftom 
>> GitHub, so this is all covered (except parts of git-trac only used by 
>> Volker-but you don't need to worry about this)
>>
>> it's explained in some detail in docs prepared by Matthias.
>>
>> Yes, indeed. "gh pr checkout" (
> https://cli.github.com/manual/gh_pr_checkout) looks like pretty much like 
> an exact analogue for "git trac checkout"
>
> What I was not able to find, though, was the equivalent of "git trac 
> push", which can sometimes be very convenient for making a small friendly 
> amendment to a proposed change. I would not expect to be able to push to 
> someone else's fork (I cannot push to someone else's branch on trac 
> anyway), but I can of course push to my own branch -- git-trac in that 
> situation pushes to a branch in my name and does the required magic to tie 
> that branch to the relevant ticket.
>
> It's not clear to me yet what the github analogue of that would be ... I 
> guess a different "pr" could be tied to a given issue. But in that case, a 
> direct analogue of "git trac" would focus on "issues", and pull the 
> currently registered "pr" for a given issue and tie my new branch as a "pr" 
> to that issue if I want to make a change to a ticket.
>
> Perhaps it's nice to address how to "make a friendly amendment" to someone 
> else's "pr" or "issue", or how to collaborate on tickets/issues/pr's . In 
> my work on trac tickets that happened quite a bit and "git trac 
> checkout/push" makes the workflow superconvenient for that. It would be 
> nice to have a convenient convention on how to replicate that on 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/a1ee452c-4706-4871-a6e3-092fae4119f0n%40googlegroups.com.

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

[Dima Pasechnik]

On Wed, 14 Sep 2022, 03:15 Nils Bruin,  wrote:

> On Tuesday, 13 September 2022 at 14:04:24 UTC-7 dim...@gmail.com wrote:
>
>>
>>
>> On Tue, 13 Sep 2022, 21:56 Nils Bruin,  wrote:
>>
>>> I'd actually be interested in knowing what the substitute for "git trac
>>> checkout ..." is. Because with trac, all ticket branches are present in the
>>> "trac" repository, you can pull anything from there. If I have to
>>> merge/pull from developer branch, do I need to add another remote to my
>>> local sage git repository? That sounds very laborious. Particularly for how
>>> to keep it up-to-date.
>>>
>>
>> No, you don't need to add the remote of the author of the PR, because the
>> PR is a branch in the main repo.
>>
>> git-trac's functionality is provided by cli, a command line tool ftom
>> GitHub, so this is all covered (except parts of git-trac only used by
>> Volker-but you don't need to worry about this)
>>
>> it's explained in some detail in docs prepared by Matthias.
>>
>> Yes, indeed. "gh pr checkout" (
> https://cli.github.com/manual/gh_pr_checkout) looks like pretty much like
> an exact analogue for "git trac checkout"
>
> What I was not able to find, though, was the equivalent of "git trac
> push", which can sometimes be very convenient for making a small friendly
> amendment to a proposed change.
>

I would not expect to be able to push to someone else's fork (I cannot push
> to someone else's branch on trac anyway), but I can of course push to my
> own branch -- git-trac in that situation pushes to a branch in my name and
> does the required magic to tie that branch to the relevant ticket.
>
> It's not clear to me yet what the github analogue of that would be ... I
> guess a different "pr" could be tied to a given issue.
>

No, not really.
The github analogue is to do a PR on the repo where the original PR came
from, repo P, say.

not sure whether gh allows an easy way to do so;
with plain git you just push your changes onto your fork (which is just a
different remote for your local git repo), and there, using web interface,
create a PR - you have a choice of upstreams to send the PR to, so you
choose the correct one, namely, repo P.
Now, the owner of repo P approves/merges your PR, and the commits there are
automatically added to the original PR (this is a "PR update").

to compare this with using plain git with trac, it's about the same
complexity, there is extra step of approving/merging done by the owner of
repo P (which is few clicks), but you don't need to mess with the new name
for the branch on trac, it's a better web UI - and only the changes the the
owner of repo P make its way into the original PR.


It would be reasonable to expect that gh should facilitate this, I'm just
not familiar with it.
(maybe it is extendable?)




But in that case, a direct analogue of "git trac" would focus on "issues",
> and pull the currently registered "pr" for a given issue and tie my new
> branch as a "pr" to that issue if I want to make a change to a ticket.
>

GitHub does not restrict you to one PR per issue, in this sense it is more
flexible. You don't have to automatically close an issue by a PR, and
anyway, the issue reporter can reopen it, it's not like trac tickets,
which, once closed, can't be easily reopened.


> Perhaps it's nice to address how to "make a friendly amendment" to someone
> else's "pr" or "issue", or how to collaborate on tickets/issues/pr's . In
> my work on trac tickets that happened quite a bit and "git trac
> checkout/push" makes the workflow superconvenient for that. It would be
> nice to have a convenient convention on how to replicate that on 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/e0a37229-9a65-40f5-aad0-106a42e6242fn%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/CAAWYfq3c%2B06uyhKsaLANgHYbjGAcSuHkae7CcZo5wz-_z1mHUw%40mail.gmail.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

[Matthias Koeppe]

On Tuesday, September 13, 2022 at 10:31:09 PM UTC-7 Nils Bruin wrote:

> On Tuesday, 13 September 2022 at 19:43:32 UTC-7 Matthias Koeppe wrote:
>
>> One way to do this is using 
>> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork
>> This is a checkmark that the author of a PR can set or unset.
>>
>
> I don't think that gives us quite the same generality. From what I 
> understand from the description there is that people *with push privilege* 
> on the actual upstream can be given permission to commit to a branch in the 
> fork. I think we want to keep the people with push privilege limited, but 
> collaboration on tickets should be widely available and easy.
>

It's easy to setup different degrees of privileges using Teams. Currently 
there's only one Team, called Core. We would be adding another, much 
larger, Team of regular developers, to which we then can assign the 
necessary permissions (but they still wouldn't be able to push to 
"develop", for example). I've written this in  
https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-permissions-and-protections


-- 
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/2ea47475-a2e8-4da9-8229-d79cb0a546b1n%40googlegroups.com.