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

On Saturday, September 17, 2022 at 5:22:06 AM UTC-7 kcrisman wrote:

> On a separate note, can someone explain to me why GL is preferable to 
>> those who prefer as open of tools as possible to GH?  At first I was under 
>> the impression that GL was not a business and was largely self-hosted, but 
>> it appears it's basically similar to GH or indeed Bitbucket (not that I'm 
>> suggesting we do BB!).  This question is *purely* technical and not 
>> intended to start a different set of arguments, i just feel that for those 
>> of us less familiar with GL it is helpful to know why it's preferable to 
>> some to GH.  (From https://about.gitlab.com/solutions/open-source/ it 
>> appears to be "open core" but with some important features only 
>> "source-available"; is that the reasoning?)
>>
>
This is great question, thanks for the pointer to this GitLab.com URL. I've 
updated 
https://github.com/sagemath/sage/wiki/Github-vs-Gitlab-vs-trac#in-favor-of-gitlab
 
based on 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/ef7ff4f5-6528-41e5-ae0e-fa49729e1804n%40googlegroups.com.

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

On Sunday, September 18, 2022 at 11:12:59 AM UTC-7 wst...@gmail.com wrote:

>
> This is a 3 minute video demoing importing github repos to gitlab, 
> which emphasizes answers to a lot of natural frequent questions 
> (involving users, issue comments, labels, etc.): 
>
> https://www.youtube.com/watch?v=VYOXuOg9tQI


I've added this 
to 
https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#retrieving-data-from-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/e76a6fed-2d29-408d-8565-4b5b5a577a03n%40googlegroups.com.

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

On Sunday, September 18, 2022 at 11:12:59 AM UTC-7 wst...@gmail.com wrote:

> In my experience, the search built into GitHub is at least 10x (or 
> maybe 100x?) faster than our trac search, e.g., try searching 
> https://trac.sagemath.org/search versus 
> https://github.com/python/cpython/issues . In addition GitHub's 
> advanced search capabilities are useful (in terms of sorting, refining 
> queries, querying by label, etc.).


I've added this 
to https://github.com/sagemath/sage/wiki/Github-vs-Gitlab-vs-trac

-- 
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/10eab99a-5a92-40de-a415-b8357ba6ba7bn%40googlegroups.com.

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

2022-09-18 Thread William Stein

On Sun, Sep 18, 2022 at 10:27 AM Matthias Koeppe
 wrote:
>
> On Sunday, September 18, 2022 at 10:14:26 AM UTC-7 Nils Bruin wrote:
>>
>> On Saturday, 17 September 2022 at 17:55:10 UTC-7 Matthias Koeppe wrote:
>>>
>>>
>>> The conversion of the Trac tickets to GitHub Issues/PRs only works in one 
>>> shot. Incrementally syncing updates from Trac to existing issues is not 
>>> possible.
>>
>>
>> Migration *to* GH is one thing, but as has been pointed out, we should have 
>> an exit strategy as well, or at least an idea of a roadmap to move from 
>> github to elsewhere. The code itself is trivial to move: it's a git repo. 
>> However, as has been shown in the past, the discussions (now in tickets on 
>> trac, but if moved in issues and PRs) can sometimes be of immense value as 
>> well. I suppose that if moving from GH to GL is as trivial as claimed 
>> before, GH must have a way of exporting issues and PRs.
>>
>> Would someone be able to give an informed assessment or a feasibility study 
>> of extracting issues and PRs from GH? How searchable are they and how do 
>> cross-links survive an extraction (also important for trac-to-GH)? 
>> Presently, trac is fairly searchable due to its own search functions plus 
>> its general indexing by google's search engine. Hopefully we'd have 
>> something at least matching that for GH.
>>
>> Perhaps part of our setup should also be that we "backup" this part of our 
>> github setup: githubs own infrastructure is of course excellently resilient 
>> against technological problems but a new failure mode is introduced due to 
>> their governance and policy: in the extremely unlikely event that sagemath 
>> on GH would get "locked" due to a misunderstanding (or malice?) we might not 
>> be at their mercy for extracting our valuable history.
>
>
> I agree that it would be valuable to add at least some starting points in 
> this direction.
> As a beginning, I have created the section:
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#retrieving-data-from-github
> to include the link https://docs.github.com/en/rest to GitHub's REST API, 
> which gives access to everything and is extremely well documented.

I used this GitHub REST API a lot recently to implement proxying of
content from GitHub to CoCalc, and it is indeed *extremely* good.

This is a 3 minute video demoing importing github repos to gitlab,
which emphasizes answers to a lot of natural frequent questions
(involving users, issue comments, labels, etc.):

https://www.youtube.com/watch?v=VYOXuOg9tQI

In my experience, the search built into GitHub is at least 10x (or
maybe 100x?) faster than our trac search, e.g., try searching
https://trac.sagemath.org/search  versus
https://github.com/python/cpython/issues .In addition GitHub's
advanced search capabilities are useful (in terms of sorting, refining
queries, querying by label, etc.).


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

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

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

On Sunday, September 18, 2022 at 10:14:26 AM UTC-7 Nils Bruin wrote:

> On Saturday, 17 September 2022 at 17:55:10 UTC-7 Matthias Koeppe wrote:
>
>>
>> The conversion of the Trac tickets to GitHub Issues/PRs only works in one 
>> shot. Incrementally syncing updates from Trac to existing issues is not 
>> possible.
>>
>
> Migration *to* GH is one thing, but as has been pointed out, we should 
> have an exit strategy as well, or at least an idea of a roadmap to move 
> from github to elsewhere. The code itself is trivial to move: it's a git 
> repo. However, as has been shown in the past, the discussions (now in 
> tickets on trac, but if moved in issues and PRs) can sometimes be of 
> immense value as well. I suppose that if moving from GH to GL is as trivial 
> as claimed before, GH must have a way of exporting issues and PRs.
>
> Would someone be able to give an informed assessment or a feasibility 
> study of extracting issues and PRs from GH? How searchable are they and how 
> do cross-links survive an extraction (also important for trac-to-GH)? 
> Presently, trac is fairly searchable due to its own search functions plus 
> its general indexing by google's search engine. Hopefully we'd have 
> something at least matching that for GH.
>
> Perhaps part of our setup should also be that we "backup" this part of our 
> github setup: githubs own infrastructure is of course excellently resilient 
> against technological problems but a new failure mode is introduced due to 
> their governance and policy: in the extremely unlikely event that sagemath 
> on GH would get "locked" due to a misunderstanding (or malice?) we might 
> not be at their mercy for extracting our valuable history.
>

I agree that it would be valuable to add at least some starting points in 
this direction.
As a beginning, I have created the section:
https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#retrieving-data-from-github
to include the link https://docs.github.com/en/rest to GitHub's REST API, 
which gives access to everything and is extremely well documented.


 

-- 
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/64de5f3b-1b76-42bd-9181-d5cb2cef96b6n%40googlegroups.com.

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

2022-09-18 Thread John H Palmieri

Another way that trac is searchable is via the Google group sage-trac. Can 
we set up a similar group if we move to Github?

On Sunday, September 18, 2022 at 10:14:26 AM UTC-7 Nils Bruin wrote:

> On Saturday, 17 September 2022 at 17:55:10 UTC-7 Matthias Koeppe wrote:
>
>>
>> The conversion of the Trac tickets to GitHub Issues/PRs only works in one 
>> shot. Incrementally syncing updates from Trac to existing issues is not 
>> possible.
>>
>
> Migration *to* GH is one thing, but as has been pointed out, we should 
> have an exit strategy as well, or at least an idea of a roadmap to move 
> from github to elsewhere. The code itself is trivial to move: it's a git 
> repo. However, as has been shown in the past, the discussions (now in 
> tickets on trac, but if moved in issues and PRs) can sometimes be of 
> immense value as well. I suppose that if moving from GH to GL is as trivial 
> as claimed before, GH must have a way of exporting issues and PRs.
>
> Would someone be able to give an informed assessment or a feasibility 
> study of extracting issues and PRs from GH? How searchable are they and how 
> do cross-links survive an extraction (also important for trac-to-GH)? 
> Presently, trac is fairly searchable due to its own search functions plus 
> its general indexing by google's search engine. Hopefully we'd have 
> something at least matching that for GH.
>
> Perhaps part of our setup should also be that we "backup" this part of our 
> github setup: githubs own infrastructure is of course excellently resilient 
> against technological problems but a new failure mode is introduced due to 
> their governance and policy: in the extremely unlikely event that sagemath 
> on GH would get "locked" due to a misunderstanding (or malice?) we might 
> not be at their mercy for extracting our valuable history.
>

-- 
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/6df70728-981a-4e8f-b5d8-7d4259a36507n%40googlegroups.com.

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

2022-09-18 Thread Nils Bruin

On Saturday, 17 September 2022 at 17:55:10 UTC-7 Matthias Koeppe wrote:

>
> The conversion of the Trac tickets to GitHub Issues/PRs only works in one 
> shot. Incrementally syncing updates from Trac to existing issues is not 
> possible.
>

Migration *to* GH is one thing, but as has been pointed out, we should have 
an exit strategy as well, or at least an idea of a roadmap to move from 
github to elsewhere. The code itself is trivial to move: it's a git repo. 
However, as has been shown in the past, the discussions (now in tickets on 
trac, but if moved in issues and PRs) can sometimes be of immense value as 
well. I suppose that if moving from GH to GL is as trivial as claimed 
before, GH must have a way of exporting issues and PRs.

Would someone be able to give an informed assessment or a feasibility study 
of extracting issues and PRs from GH? How searchable are they and how do 
cross-links survive an extraction (also important for trac-to-GH)? 
Presently, trac is fairly searchable due to its own search functions plus 
its general indexing by google's search engine. Hopefully we'd have 
something at least matching that for GH.

Perhaps part of our setup should also be that we "backup" this part of our 
github setup: githubs own infrastructure is of course excellently resilient 
against technological problems but a new failure mode is introduced due to 
their governance and policy: in the extremely unlikely event that sagemath 
on GH would get "locked" due to a misunderstanding (or malice?) we might 
not be at their mercy for extracting our valuable history.

-- 
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/0e2df7b4-3dca-4b1c-b93c-2e893673b687n%40googlegroups.com.

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

2022-09-18 Thread Dima Pasechnik

On Sun, 18 Sep 2022, 01:44 Kwankyu Lee,  wrote:

> On Friday, September 16, 2022 at 6:30:05 PM UTC+9 dim...@gmail.com wrote:
>
> I'd rather focus the vote primarily on the move away from trac, ...
>
>
> What would the move mean precisely? As there are two things to be done
>
> (1) The release manager declares to merge tickets only from Github, not
> from Trac.
> (2) Trac goes to read-only mode.
>
> the move can mean
>
> (a) First (1) and then after some time (2)
>
> or
>
> (b) (1) and (2) at the same time.
>
> I think it should be (a) as we want to clean up trac (and final good-bye).
>

the idea is that what we have on Trac will be moved to GitHub. So the
cleanup may be done there, and we can go straight to (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/0bc0cdc4-c6c8-4e10-bd50-a9bde519c36en%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/CAAWYfq0xfKmObZoVVMHJ9jZLf4bR1OwiTdZwEsdYjaz%3Dj8xPmQ%40mail.gmail.com.

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

2022-09-17 Thread Matthias Koeppe

On Saturday, September 17, 2022 at 8:43:55 PM UTC-7 Kwankyu Lee wrote:

> On Sunday, September 18, 2022 at 9:55:10 AM UTC+9 Matthias Koeppe wrote:
>
>> The conversion of the Trac tickets to GitHub Issues/PRs only works in one 
>> shot. Incrementally syncing updates from Trac to existing issues is not 
>> possible.
>> This means that we cannot continue to operate Trac after the switch.
>>
>
> That means (1) and (2) at the same time.
>
> I understand that the conversion is one shot process. But that does not 
> technically force trac to be read-only. I suspect that there may be still 
> some occasions to leave comments or something on trac after the migration. 
>

No, these comments will have to go to the issue / PR that is the result of 
the conversion from that ticket.

 

-- 
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/c190a404-375b-46dd-8a07-6c7d61919dcan%40googlegroups.com.

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

2022-09-17 Thread Kwankyu Lee

On Sunday, September 18, 2022 at 9:55:10 AM UTC+9 Matthias Koeppe wrote:

> The conversion of the Trac tickets to GitHub Issues/PRs only works in one 
> shot. Incrementally syncing updates from Trac to existing issues is not 
> possible.
> This means that we cannot continue to operate Trac after the switch.
>

That means (1) and (2) at the same time.

I understand that the conversion is one shot process. But that does not 
technically force trac to be read-only. I suspect that there may be still 
some occasions to leave comments or something on trac after the migration. 
Perhaps just my imaginary concern...

Okay. Thanks. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3580f98e-b869-49cd-a03a-5131cc786a70n%40googlegroups.com.

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

2022-09-17 Thread Matthias Koeppe

On Saturday, September 17, 2022 at 5:44:52 PM UTC-7 Kwankyu Lee wrote:

> On Friday, September 16, 2022 at 6:30:05 PM UTC+9 dim...@gmail.com wrote:
>
> I'd rather focus the vote primarily on the move away from trac, ...
>
>
> What would the move mean precisely? As there are two things to be done
>
> (1) The release manager declares to merge tickets only from Github, not 
> from Trac.
> (2) Trac goes to read-only mode. 
>
> the move can mean
>
> (a) First (1) and then after some time (2) 
>
> or 
>
> (b) (1) and (2) at the same time.
>

The conversion of the Trac tickets to GitHub Issues/PRs only works in one 
shot. Incrementally syncing updates from Trac to existing issues is not 
possible.
This means that we cannot continue to operate Trac after the switch.

-- 
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/20608f08-46d8-489c-aae4-ce0cd2175e89n%40googlegroups.com.

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

2022-09-17 Thread Kwankyu Lee

On Friday, September 16, 2022 at 6:30:05 PM UTC+9 dim...@gmail.com wrote:

I'd rather focus the vote primarily on the move away from trac, ...


What would the move mean precisely? As there are two things to be done

(1) The release manager declares to merge tickets only from Github, not 
from Trac.
(2) Trac goes to read-only mode. 

the move can mean

(a) First (1) and then after some time (2) 

or 

(b) (1) and (2) at the same time.

I think it should be (a) as we want to clean up trac (and final good-bye).





-- 
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/0bc0cdc4-c6c8-4e10-bd50-a9bde519c36en%40googlegroups.com.

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

2022-09-17 Thread Dima Pasechnik

On Sat, 17 Sep 2022, 13:22 kcrisman,  wrote:

>
> I think the 1st vote should be on moving from trac to Git**b; besides it
>> appears that, technically, move to Github is much easier than to Gitlab
>> (while there are migration tools available for trac->github, I could not
>> find anything for trac->gitlab).
>>
>> On the other hand github->gitlab move is easy (that's where gitlab gets
>> its business from).
>>
>
> Thanks for confirming that, this makes it clearer what the *current*
> options are (simplifying the voting, whether 1/2 or 2/3 or 601/1200 or ...).
>
> On a separate note, can someone explain to me why GL is preferable to
> those who prefer as open of tools as possible to GH?  At first I was under
> the impression that GL was not a business and was largely self-hosted, but
> it appears it's basically similar to GH or indeed Bitbucket (not that I'm
> suggesting we do BB!).  This question is *purely* technical and not
> intended to start a different set of arguments, i just feel that for those
> of us less familiar with GL it is helpful to know why it's preferable to
> some to GH.  (From https://about.gitlab.com/solutions/open-source/ it
> appears to be "open core" but with some important features only
> "source-available"; is that the reasoning?)
>

basically the main difference is that one can self-host an instance of GL
themselves, without paying anything. This is certainly not very easy, to do
such hosting, but still.

Otherwise GL lacks in freely available features, compared to GH (and
basically mostly copies what GH provides, with several important things
lagging behind).


-- 
> 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/4b4aab3b-7067-4106-86cf-6b09f3448031n%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/CAAWYfq0oM1GkFxQEOmBh_ymPDiyFk27H-w67NYva2LCdCM%2ByOg%40mail.gmail.com.

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

2022-09-17 Thread kcrisman



> I think the 1st vote should be on moving from trac to Git**b; besides it 
> appears that, technically, move to Github is much easier than to Gitlab 
> (while there are migration tools available for trac->github, I could not 
> find anything for trac->gitlab).
>
> On the other hand github->gitlab move is easy (that's where gitlab gets 
> its business from).
>

Thanks for confirming that, this makes it clearer what the *current* 
options are (simplifying the voting, whether 1/2 or 2/3 or 601/1200 or ...).

On a separate note, can someone explain to me why GL is preferable to those 
who prefer as open of tools as possible to GH?  At first I was under the 
impression that GL was not a business and was largely self-hosted, but it 
appears it's basically similar to GH or indeed Bitbucket (not that I'm 
suggesting we do BB!).  This question is *purely* technical and not 
intended to start a different set of arguments, i just feel that for those 
of us less familiar with GL it is helpful to know why it's preferable to 
some to GH.  (From https://about.gitlab.com/solutions/open-source/ it 
appears to be "open core" but with some important features only 
"source-available"; is that the reasoning?)

-- 
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/4b4aab3b-7067-4106-86cf-6b09f3448031n%40googlegroups.com.

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

2022-09-16 Thread William Stein

On Fri, Sep 16, 2022 at 12:34 PM Dima Pasechnik  wrote:
>> - Some people with strong opinions said that they are not ready to formulate 
>> their views.
>>
>> My impression is that trac is now doing okay,
>
>
> Note that trac's bus factor is down to 1/3. It took efforts of Frederick, 
> Jan, and me to put it into the present state.
> Any kind of system upgrade, or VM infrastructure update, or something else, 
> may break it,
> with all 3 of us possibily needed to repair it. Maybe we'd manage, maybe not.

This is very relevant, since Google is charging us an *extra* $100
month for some mysterious artifact caused by
an ancient App Engine test that was done in 2018.  There is absolutely
no possible way to disable that charge,
as I confirmed after a dozen emails back and forth using my serious
Google support contract from work -- the
only option is to completely delete all current infrastructure and
migrate it to a new project.  This is scary
because "Any kind of system upgrade, or VM infrastructure update,  or
something else, may break it,", and
yet exactly that needs to happen to stop this charge.   Yes, I am
trying to get  Google to credit our account for
the unfair charge, but that hasn't succeeded yet either, as Google
clearly isn't "officially not evil" in an ethical
sense anymore.

Just the price for Google Cloud for trac right now is the same as the
professional GitHub Teams subscription for an org
with around  50 people, which we don't need (since open source), but
it's a relevant comparison.

> I don't think it is an acceptable state of affairs, and that's why it really 
> is strange for me that we are bothering with the vote at all.

I'm extremely appreciative that the sage devs such as Dima are taking
the very real problems of Sage's
dev infrastructure so very seriously right now.

William

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

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

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

On Fri, 16 Sep 2022, 19:54 John H Palmieri,  wrote:

> A few comments:
>
> - We have a strong history in Sage of conducting votes, and I absolutely
> think we need to do that for this issue. We also have a history (with
> perhaps a small number of exceptions) of having majority rule, and I think
> that's what we should do here: no need for a 2/3 vote.
>
> An aside: I am chair of our department, and we have a governance
> structure, including an executive committee. Earlier this year the
> committee proposed a policy to the whole department and brought it to a
> meeting for a vote. The discussion was contentious and the vote ended up
> with more yes than no votes, but there were also a number of abstentions,
> and the total number of yes votes was under 50% of the total present.
> Shortly after, I proposed, and the executive committee accepted, that we
> not put the new policy into place: our department has a strong preference
> for something closer to consensus than that. Sage does not have any such
> governance structure, so I don't think we can behave this way: we can't
> wait until the votes are cast before deciding how to interpret the results
> (not that anyone was proposing this), but I also think we can't decide that
> this vote should require a supermajority. It feels very arbitrary: why this
> vote but not so many others? We should hold a vote where the majority wins.
> If we want to develop more of a structure, including some sort of criteria
> for when we want majority votes vs. supermajority votes, we can do that,
> but I don't think it makes sense to try to put it in place for this issue.
>
> - Regarding Gitlab: there has been very little discussion of it: the
> discussion has focused on Github and trac. If we are expected to consider
> Gitlab in addition, we need more information. In particular, starting a
> vote early next week is too early.
>

I think the 1st vote should be on moving from trac to Git**b; besides it
appears that, technically, move to Github is much easier than to Gitlab
(while there are migration tools available for trac->github, I could not
find anything for trac->gitlab).

On the other hand github->gitlab move is easy (that's where gitlab gets its
business from).


> - Some people with strong opinions said that they are not ready to
> formulate their views.
>
> My impression is that trac is now doing okay,
>

Note that trac's bus factor is down to 1/3. It took efforts of Frederick,
Jan, and me to put it into the present state.
Any kind of system upgrade, or VM infrastructure update, or something else,
may break it,
with all 3 of us possibily needed to repair it. Maybe we'd manage, maybe
not.

I don't think it is acceptable state of affairs, and that's why it really
is strange for me that we are bothering with the vote at all.

Dima

and I don't see a reason to rush a vote. I would propose that people work
> on David's list of pros and cons (thank you for working on that!), and we
> start a vote around October 1. We may or may not want to include Gitlab
> among the options; are there any actual proponents of it?
>
> --
> John
>
>
>
> On Friday, September 16, 2022 at 1:19:35 AM UTC-7 David Roe wrote:
>
>> I've started working on a list of pros and cons
>>  to be
>> included in the email proposing a vote.  Even though I favor the switch,
>> I've tried to accurately and neutrally describe the arguments in each
>> direction.  I welcome help and additions, but please keep them in this
>> spirit (conversely, if you feel like I'm misrepresenting an argument or
>> making unjustified claims, please let me know).
>>
>> There has also been some discussion of how the vote should be carried out.
>>
>> * There was a proposal to make the deadline two weeks after the call for
>> the vote.  That sounds fine to me.
>> * I intend to include a plea for people to keep discussion on a separate
>> thread rather than the voting thread.
>> * There was a proposal for people who have been more involved somehow to
>> have their votes count extra.  I don't think this is a good idea: it's not
>> clear how to draw the line or what the weighting should be, and I think
>> it's more likely to cause resentment than alleviate it.
>> * There hasn't been much discussion of Github vs Gitlab on this thread,
>> but theoretically there are three choices in play.  Given that, we face
>> Arrow's theorem in picking a voting system (especially if we also want to
>> allow people to abstain).  I'm normally in favor of a Borda count
>>  variant, but with three
>> options and Github and Gitlab more similar to each other than to trac, I
>> propose Ranked pairs  for a
>> voting system.  I suspect there may be voting theory experts lurking, so
>> I'm happy to hear other opinions.
>> * There was a proposal to require 2/3 either in favor of a switch or not
>> opposing.  I'm open

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

2022-09-16 Thread John H Palmieri

A few comments:

- We have a strong history in Sage of conducting votes, and I absolutely 
think we need to do that for this issue. We also have a history (with 
perhaps a small number of exceptions) of having majority rule, and I think 
that's what we should do here: no need for a 2/3 vote.

An aside: I am chair of our department, and we have a governance structure, 
including an executive committee. Earlier this year the committee proposed 
a policy to the whole department and brought it to a meeting for a vote. 
The discussion was contentious and the vote ended up with more yes than no 
votes, but there were also a number of abstentions, and the total number of 
yes votes was under 50% of the total present. Shortly after, I proposed, 
and the executive committee accepted, that we not put the new policy into 
place: our department has a strong preference for something closer to 
consensus than that. Sage does not have any such governance structure, so I 
don't think we can behave this way: we can't wait until the votes are cast 
before deciding how to interpret the results (not that anyone was proposing 
this), but I also think we can't decide that this vote should require a 
supermajority. It feels very arbitrary: why this vote but not so many 
others? We should hold a vote where the majority wins. If we want to 
develop more of a structure, including some sort of criteria for when we 
want majority votes vs. supermajority votes, we can do that, but I don't 
think it makes sense to try to put it in place for this issue.

- Regarding Gitlab: there has been very little discussion of it: the 
discussion has focused on Github and trac. If we are expected to consider 
Gitlab in addition, we need more information. In particular, starting a 
vote early next week is too early.

- Some people with strong opinions said that they are not ready to 
formulate their views.

My impression is that trac is now doing okay, and I don't see a reason to 
rush a vote. I would propose that people work on David's list of pros and 
cons (thank you for working on that!), and we start a vote around October 
1. We may or may not want to include Gitlab among the options; are there 
any actual proponents of it?

-- 
John

On Friday, September 16, 2022 at 1:19:35 AM UTC-7 David Roe wrote:

> I've started working on a list of pros and cons 
>  to be 
> included in the email proposing a vote.  Even though I favor the switch, 
> I've tried to accurately and neutrally describe the arguments in each 
> direction.  I welcome help and additions, but please keep them in this 
> spirit (conversely, if you feel like I'm misrepresenting an argument or 
> making unjustified claims, please let me know).
>
> There has also been some discussion of how the vote should be carried out.
>
> * There was a proposal to make the deadline two weeks after the call for 
> the vote.  That sounds fine to me.
> * I intend to include a plea for people to keep discussion on a separate 
> thread rather than the voting thread.
> * There was a proposal for people who have been more involved somehow to 
> have their votes count extra.  I don't think this is a good idea: it's not 
> clear how to draw the line or what the weighting should be, and I think 
> it's more likely to cause resentment than alleviate it.
> * There hasn't been much discussion of Github vs Gitlab on this thread, 
> but theoretically there are three choices in play.  Given that, we face 
> Arrow's theorem in picking a voting system (especially if we also want to 
> allow people to abstain).  I'm normally in favor of a Borda count 
>  variant, but with three 
> options and Github and Gitlab more similar to each other than to trac, I 
> propose Ranked pairs  for a 
> voting system.  I suspect there may be voting theory experts lurking, so 
> I'm happy to hear other opinions.
> * There was a proposal to require 2/3 either in favor of a switch or not 
> opposing.  I'm open to this, but would be interested in hearing other 
> opinions.  Perhaps we allow people to abstain, and then require that at 
> least 2/3 either abstain or prefer the winner to trac?  With this in place, 
> maybe our voting system doesn't actually matter, but it's probably safer to 
> pick one.
>
> Given that I want to get feedback on the voting system and the 
> pros-and-cons, I'll wait until at least Monday to send out a request for a 
> vote (longer if the discussion is still going strong or if the workflow 
> proposal 
>  is 
> still in flux).
> David
>
> On Fri, Sep 16, 2022 at 3:41 AM Matthias Koeppe  
> wrote:
>
>> On Thursday, September 15, 2022 at 11:57:35 PM UTC-7 seb@gmail.com 
>> wrote:
>>
>>> About ten years before Google was on Earth someone put a poster on our 
>>> corridor of the University

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

2022-09-16 Thread Matthias Koeppe

On Friday, September 16, 2022 at 3:08:20 AM UTC-7 Eric Gourgoulhon wrote:

> Le jeudi 15 septembre 2022 à 18:34:22 UTC+2, Matthias Koeppe a écrit :
>
>> On Thursday, September 15, 2022 at 9:04:09 AM UTC-7 Matthias Koeppe wrote:
>>
>>> On Thursday, September 15, 2022 at 6:21:09 AM UTC-7 Eric Gourgoulhon 
>>> wrote:
>>>
 I don't understand why in the post
 https://groups.google.com/g/sage-devel/c/QooOF1GLMOs
 Matthias asked to remove developer names from 
 (1) https://trac.sagemath.org/#AccountNamesMappedtoRealNames
 Aren't we loosing information here?
 I of course understand there is now 
 https://github.com/sagemath/website/blob/master/conf/contributors.xml
 and that duplication is the root of all evil, but if a read-only mirror 
 of Trac is maintained, the list (1) would be useful to contact a Sage 
 developer regarding a specific ticket. 

>>>
>>> No, the data is not lost. It is *migrated* to 
>>> https://github.com/sagemath/website/blob/master/conf/contributors.xml, 
>>> where it will be preserved (including the Trac usernames).
>>>
>>
>> To add to this: The purpose of my request to remove your info after 
>> merging it into contributors.xml is the following:
>> In 2 weeks or so, I'll bulk-merge the remaining info into 
>> contributors.xml; and I will do a cursory review of each item. 
>> By removing your already-merged data from the source, you'll save me the 
>> time to check which of the information (in contributors.xml or Trac) is 
>> more current. 
>>
>
> OK, I've then removed my name from the Trac list.  
>

Thanks!
 

> Anyway, since the latest upgrade of Trac, real names appear on the 
> tickets, instead of user names, which makes the original Trac list less 
> useful.
>
>
Yes, that's right.
 

-- 
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/b01925d4-e603-43d8-b9cc-4881d649e7f9n%40googlegroups.com.

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

On Fri, 16 Sep 2022, 17:20 kcrisman,  wrote:

>
> I'd rather focus the vote primarily on the move away from trac, not
>> specifying whether it's GitHub or GitLab.
>>
>>
>>
>> > Given that, we face Arrow's theorem in picking a voting system
>> (especially if we also want to allow people to abstain). I'm normally in
>> favor of a Borda count variant, but with three options and Github and
>> Gitlab more similar to each other than to trac, I propose Ranked pairs for
>> a voting system. I suspect there may be voting theory experts lurking, so
>> I'm happy to hear other opinions.
>>
>> I'll have a word with my in-house voting theory expert :-)
>>
>
> Who will surely point out the inseparability of the various yes/no options
> here.  Voting system choice is more a sociological matter, in my view,
> which I think is well supported by the arguments of the authors of
> "Properties of Multiwinner Voting Rules, Soc. Ch. Welf. 48:599-632" about
> different goals for "committee" choices in different contexts.
>
> > * There was a proposal to require 2/3 either in favor of a switch or not
>> opposing. I'm open to this, but would be interested in hearing other
>> opinions. Perhaps we allow people to abstain, and then require that at
>> least 2/3 either abstain or prefer the winner to trac? With this in place,
>> maybe our voting system doesn't actually matter, but it's probably safer to
>> pick one.
>>
>> I don't see why all of a sudden we talk about 2/3rds, not a simple
>> majority. Have we ever had a vote which was not a simple majority vote
>> here?
>>
>
> This was my suggestion (suggestion only).  Namely, with a 2/3 vote, half
> the people who voted in favor would have to change their mind to then vote
> for a different switch.  (Of course, the place that most benefits is if all
> votes are 2/3, which wouldn't be the case here.)  I do feel like we have
> had one or two "supermajority" consensus-seeking situations, but not
> formally so, and no, I can't find them now.
>
> The primary reason I suggested it, though, was to take the emphasis away
> from the controversial aspect, and have the community feel like whatever
> decision is made is one there is strong support for, which then the rest
> might grudgingly agree to for the good of the project (in a worst-case
> scenario; my hope is no grudges!).  Moving to GH to potentially attract new
> developers isn't super helpful if a significant number of long-time,
> *experienced* developers might leave;
>
likewise, staying on Trac isn't helpful if some developers (and
> particularly maintainers) say they just can't do it any more because it's
> so broken.
>
 So this is a real danger.  Since a choice of system could lead to a very
> divisive result, or alternately be too confusing for many people to fully
> participate, I made a possible suggestion.
>
> However the vote is structured (yes, we voting theorists also do stupid
> things like voting on voting systems ...), in my view the primary
> importance is finding a solution that dozens of our most valuable
> contributors (front-end and back-end) can at least live with, and then have
> a purely pro forma vote on that.  Otherwise we could have literally dozens
> of options, many of which it's unclear from this thread whether they are
> even realistic.   Is the following link helpful in that regard?
>
>
> https://docs.gitlab.com/ee/user/project/import/github.html#mirror-a-repository-and-share-pipeline-status
>
> It seems like it really would be possible to move to GH, and then have any
> interested volunteers who care deeply about GH versus GL set up a mirror.
>  (Presumably Premium GL is still a lot cheaper than Google Cloud hosting of
> Trac?  That might be wrong.)  Or even to set up a self-hosted GL mirror on
> an academic account.
>

bility to set up any infrastructure on academic premises is more of wishful
thinking.
It's next to impossible due to too much red tape - and lack of reliability.


   I feel like something along these lines would a) not waste the effort
> already made at putting together a proposal to move to GH b) alleviate some
> concerns over GH longevity/policies c) put the work on the GH move on
> people who want to leave Trac and the work on a GL move on those who want
> to stay, so such load seems more equitable.
>
> Perhaps one could then have a true (even majority up/down) vote on leaving
> Trac, with the understanding that there is no objection or even
> encouragement to finding GH substitutes to stand in if/when necessary,
> maybe even for syncing.
>

Indeed, this would simplify the thing a lot.


Sort of like how many of the 13 North American British colonies only voted
> for the Constitution with the guarantee (implicit) that the Bill of Rights
> would be immediately forthcoming ... nah, that's a bit too dramatic!
>

we live here without a written construction, akin to UK. It only worked in
UK (and for Sage) while it was understood and maintained that unwritten
rules of gentleman-like conduct are

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

2022-09-16 Thread kcrisman



> I'd rather focus the vote primarily on the move away from trac, not 
> specifying whether it's GitHub or GitLab. 
>
>
>
> > Given that, we face Arrow's theorem in picking a voting system 
> (especially if we also want to allow people to abstain). I'm normally in 
> favor of a Borda count variant, but with three options and Github and 
> Gitlab more similar to each other than to trac, I propose Ranked pairs for 
> a voting system. I suspect there may be voting theory experts lurking, so 
> I'm happy to hear other opinions. 
>
> I'll have a word with my in-house voting theory expert :-) 
>

Who will surely point out the inseparability of the various yes/no options 
here.  Voting system choice is more a sociological matter, in my view, 
which I think is well supported by the arguments of the authors of 
"Properties of Multiwinner Voting Rules, Soc. Ch. Welf. 48:599-632" about 
different goals for "committee" choices in different contexts.

> * There was a proposal to require 2/3 either in favor of a switch or not 
> opposing. I'm open to this, but would be interested in hearing other 
> opinions. Perhaps we allow people to abstain, and then require that at 
> least 2/3 either abstain or prefer the winner to trac? With this in place, 
> maybe our voting system doesn't actually matter, but it's probably safer to 
> pick one. 
>
> I don't see why all of a sudden we talk about 2/3rds, not a simple 
> majority. Have we ever had a vote which was not a simple majority vote 
> here?
>

This was my suggestion (suggestion only).  Namely, with a 2/3 vote, half 
the people who voted in favor would have to change their mind to then vote 
for a different switch.  (Of course, the place that most benefits is if all 
votes are 2/3, which wouldn't be the case here.)  I do feel like we have 
had one or two "supermajority" consensus-seeking situations, but not 
formally so, and no, I can't find them now.

The primary reason I suggested it, though, was to take the emphasis away 
from the controversial aspect, and have the community feel like whatever 
decision is made is one there is strong support for, which then the rest 
might grudgingly agree to for the good of the project (in a worst-case 
scenario; my hope is no grudges!).  Moving to GH to potentially attract new 
developers isn't super helpful if a significant number of long-time, 
*experienced* developers might leave; likewise, staying on Trac isn't 
helpful if some developers (and particularly maintainers) say they just 
can't do it any more because it's so broken.  So this is a real danger. 
 Since a choice of system could lead to a very divisive result, or 
alternately be too confusing for many people to fully participate, I made a 
possible suggestion.

However the vote is structured (yes, we voting theorists also do stupid 
things like voting on voting systems ...), in my view the primary 
importance is finding a solution that dozens of our most valuable 
contributors (front-end and back-end) can at least live with, and then have 
a purely pro forma vote on that.  Otherwise we could have literally dozens 
of options, many of which it's unclear from this thread whether they are 
even realistic.   Is the following link helpful in that regard?  

https://docs.gitlab.com/ee/user/project/import/github.html#mirror-a-repository-and-share-pipeline-status

It seems like it really would be possible to move to GH, and then have any 
interested volunteers who care deeply about GH versus GL set up a mirror. 
 (Presumably Premium GL is still a lot cheaper than Google Cloud hosting of 
Trac?  That might be wrong.)  Or even to set up a self-hosted GL mirror on 
an academic account.I feel like something along these lines would a) 
not waste the effort already made at putting together a proposal to move to 
GH b) alleviate some concerns over GH longevity/policies c) put the work on 
the GH move on people who want to leave Trac and the work on a GL move on 
those who want to stay, so such load seems more equitable.

Perhaps one could then have a true (even majority up/down) vote on leaving 
Trac, with the understanding that there is no objection or even 
encouragement to finding GH substitutes to stand in if/when necessary, 
maybe even for syncing.  Sort of like how many of the 13 North American 
British colonies only voted for the Constitution with the guarantee 
(implicit) that the Bill of Rights would be immediately forthcoming ... 
nah, that's a bit too dramatic!

-- 
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/f92bd0d2-f732-4abd-b874-ffbbe6df2189n%40googlegroups.com.

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

2022-09-16 Thread Eric Gourgoulhon

Le jeudi 15 septembre 2022 à 18:34:22 UTC+2, Matthias Koeppe a écrit :

> On Thursday, September 15, 2022 at 9:04:09 AM UTC-7 Matthias Koeppe wrote:
>
>> On Thursday, September 15, 2022 at 6:21:09 AM UTC-7 Eric Gourgoulhon 
>> wrote:
>>
>>> I don't understand why in the post
>>> https://groups.google.com/g/sage-devel/c/QooOF1GLMOs
>>> Matthias asked to remove developer names from 
>>> (1) https://trac.sagemath.org/#AccountNamesMappedtoRealNames
>>> Aren't we loosing information here?
>>> I of course understand there is now 
>>> https://github.com/sagemath/website/blob/master/conf/contributors.xml
>>> and that duplication is the root of all evil, but if a read-only mirror 
>>> of Trac is maintained, the list (1) would be useful to contact a Sage 
>>> developer regarding a specific ticket. 
>>>
>>
>> No, the data is not lost. It is *migrated* to 
>> https://github.com/sagemath/website/blob/master/conf/contributors.xml, 
>> where it will be preserved (including the Trac usernames).
>>
>
> To add to this: The purpose of my request to remove your info after 
> merging it into contributors.xml is the following:
> In 2 weeks or so, I'll bulk-merge the remaining info into 
> contributors.xml; and I will do a cursory review of each item. 
> By removing your already-merged data from the source, you'll save me the 
> time to check which of the information (in contributors.xml or Trac) is 
> more current. 
>

OK, I've then removed my name from the Trac list.  Anyway, since the latest 
upgrade of Trac, real names appear on the tickets, instead of user names, 
which makes the original Trac list less useful.

Eric.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8ee9a196-011d-461f-b581-dbd33227073fn%40googlegroups.com.

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

On Fri, Sep 16, 2022 at 9:19 AM David Roe  wrote:
>
> I've started working on a list of pros and cons to be included in the email 
> proposing a vote.  Even though I favor the switch, I've tried to accurately 
> and neutrally describe the arguments in each direction.  I welcome help and 
> additions, but please keep them in this spirit (conversely, if you feel like 
> I'm misrepresenting an argument or making unjustified claims, please let me 
> know).
>
> There has also been some discussion of how the vote should be carried out.
>
> * There was a proposal to make the deadline two weeks after the call for the 
> vote.  That sounds fine to me.
> * I intend to include a plea for people to keep discussion on a separate 
> thread rather than the voting thread.
> * There was a proposal for people who have been more involved somehow to have 
> their votes count extra.  I don't think this is a good idea: it's not clear 
> how to draw the line or what the weighting should be, and I think it's more 
> likely to cause resentment than alleviate it.

But on the other hand, if, say, the release manager didn't want to
move (like Jeroen did in the past) then
we wouldn't be able to move (without finding another release manager).
Saying this, looks like the release manager should have (almost) veto
powers here.

> * There hasn't been much discussion of Github vs Gitlab on this thread, but 
> theoretically there are three choices in play.

I think that given my negative experience with GitLab, I won't want to
even consider participating in a potential trac -> GitLab move, this
is technically trickier, due to different low-level APIs to be used in
migration tools.
And GitLab is not in a very good shape in general, compared to GitLab;
we don't want to spent a lot of effort to move to a platform that
might fold in some way soon.

Besides, given our extensive use of GitHub CI (Actions), and
uselessness of the corresponding GitLab options,
GitHub is a clear preference. Integrating GitHub Actions with a GitLab
repo, or finding a way to use GitLab for CI is an extra burden.
Everyone who prefers GitLab  should be asked a question whether he'd
be willing to work
on these rather tricky and thankless tasks.

I'd rather focus the vote primarily on the move away from trac, not
specifying whether it's GitHub or GitLab.

>  Given that, we face Arrow's theorem in picking a voting system (especially 
> if we also want to allow people to abstain).  I'm normally in favor of a 
> Borda count variant, but with three options and Github and Gitlab more 
> similar to each other than to trac, I propose Ranked pairs for a voting 
> system.  I suspect there may be voting theory experts lurking, so I'm happy 
> to hear other opinions.

I'll have a word with my in-house voting theory expert :-)

> * There was a proposal to require 2/3 either in favor of a switch or not 
> opposing.  I'm open to this, but would be interested in hearing other 
> opinions.  Perhaps we allow people to abstain, and then require that at least 
> 2/3 either abstain or prefer the winner to trac?  With this in place, maybe 
> our voting system doesn't actually matter, but it's probably safer to pick 
> one.

I don't see why all of a sudden we talk about 2/3rds, not a simple
majority. Have we ever had a vote which was not a simple majority vote
here? In the absense of a written "constitution", i.e. in a
precedence-based system, deviating from
the existing precedence requires a separate action (maybe in form of a
civil war :-)).
If we must vote on this topc (as you know, I'm against this) let's do
simple majority.

Dima

>
> Given that I want to get feedback on the voting system and the pros-and-cons, 
> I'll wait until at least Monday to send out a request for a vote (longer if 
> the discussion is still going strong or if the workflow proposal is still in 
> flux).

> David
>
> On Fri, Sep 16, 2022 at 3:41 AM Matthias Koeppe  
> wrote:
>>
>> On Thursday, September 15, 2022 at 11:57:35 PM UTC-7 seb@gmail.com wrote:
>>>
>>> About ten years before Google was on Earth someone put a poster on our 
>>> corridor of the University building: Microsoft free area. We all were proud 
>>> about that. But at that point nobody knew what should come later on.
>>
>>
>> Of course. Many of us shared this position back in the days when Microsoft 
>> was absolutely hostile to open source and in particular to the GPL.
>>
>> But it's just not applicable today. Microsoft (which GitHub is a subsidiary 
>> of) is the single biggest contributor to open source software.
>>
>>
>>
>> --
>> 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/867d0ba7-22e6-466e-8350-b660c312992dn%40googlegroups.com.
>
> --
> You received this message

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

Hi Seb,

On Fri, Sep 16, 2022 at 7:57 AM seb@gmail.com  wrote:
>
> Matthias Koeppe schrieb am Donnerstag, 15. September 2022 um 21:22:25 UTC+2:
>>
>> On Thursday, September 15, 2022 at 2:09:23 AM UTC-7 Samuel Lelievre wrote:
>>>
>>> c. Several people refuse to open a GitHub account
>>
>>
>> I don't know anyone who does. I think they should speak up for themselves 
>> (unless they also refuse to participate in this list hosted on Google) so we 
>> can understand what their concern is.
>>
>>
>
>
> Potentially, I'm that kind of person and I think it is very important that 
> Samuel posted these points!
>
> About ten years before Google was on Earth someone put a poster on our 
> corridor of the University building: Microsoft free area. We all were proud 
> about that. But at that point nobody knew what should come later on.
>
> In the 80ties Germany planned a nationwide census to happen once in a decade. 
> I joined the resistance against it. From today's point of view this is 
> absolutely ridiculous. Each day people sell much more sensitive data to many 
> powerful companies and it is much less clear how they deal with your data.
>
> It has become really hard to refuse all the things you would like to and you 
> are forced to make exceptions. Until Corona I refused to use a smartphone. 
> Now I use my employer's iPhone. But I use it less than 2 minutes a day (most 
> of that 2FA and just WiFi).


Normally one can do 2FA without a smartphone (it's true that an
SMS-only 2FA requires a phone, not necessarily smart). I wrote about
it here just yesterday.
https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/7jglobb1FgAJ

Git**b's 2FA systems are not SMS-only and therefore can be dealt with
without a  phone, smart or basic.

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

so it's really a purely political choice, whether to get a GitHub
account, no extra physical pieces of technology are needed. All GitHub
asks for is an email address.

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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/f1ba1b29-6fda-4873-8e44-c0a4b117e52an%40googlegroups.com.

-- 
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/CAAWYfq0auErMQPjm0qDPmkBErj7R7c3_7AJCWJW%3DXQmNjE7Kzw%40mail.gmail.com.

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

2022-09-16 Thread David Roe

I've started working on a list of pros and cons
 to be
included in the email proposing a vote.  Even though I favor the switch,
I've tried to accurately and neutrally describe the arguments in each
direction.  I welcome help and additions, but please keep them in this
spirit (conversely, if you feel like I'm misrepresenting an argument or
making unjustified claims, please let me know).

There has also been some discussion of how the vote should be carried out.

* There was a proposal to make the deadline two weeks after the call for
the vote.  That sounds fine to me.
* I intend to include a plea for people to keep discussion on a separate
thread rather than the voting thread.
* There was a proposal for people who have been more involved somehow to
have their votes count extra.  I don't think this is a good idea: it's not
clear how to draw the line or what the weighting should be, and I think
it's more likely to cause resentment than alleviate it.
* There hasn't been much discussion of Github vs Gitlab on this thread, but
theoretically there are three choices in play.  Given that, we face Arrow's
theorem in picking a voting system (especially if we also want to allow
people to abstain).  I'm normally in favor of a Borda count
 variant, but with three options
and Github and Gitlab more similar to each other than to trac, I propose Ranked
pairs  for a voting system.  I
suspect there may be voting theory experts lurking, so I'm happy to hear
other opinions.
* There was a proposal to require 2/3 either in favor of a switch or not
opposing.  I'm open to this, but would be interested in hearing other
opinions.  Perhaps we allow people to abstain, and then require that at
least 2/3 either abstain or prefer the winner to trac?  With this in place,
maybe our voting system doesn't actually matter, but it's probably safer to
pick one.

Given that I want to get feedback on the voting system and the
pros-and-cons, I'll wait until at least Monday to send out a request for a
vote (longer if the discussion is still going strong or if the workflow
proposal
 is
still in flux).
David

On Fri, Sep 16, 2022 at 3:41 AM Matthias Koeppe 
wrote:

> On Thursday, September 15, 2022 at 11:57:35 PM UTC-7 seb@gmail.com
> wrote:
>
>> About ten years before Google was on Earth someone put a poster on our
>> corridor of the University building: *Microsoft free area*. We all were
>> proud about that. But at that point nobody knew what should come later on.
>>
>
> Of course. Many of us shared this position back in the days when Microsoft
> was absolutely hostile to open source and in particular to the GPL.
>
> But it's just not applicable today. Microsoft (which GitHub is a
> subsidiary of) is the single biggest contributor to open source software.
>
>
>
> --
> 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/867d0ba7-22e6-466e-8350-b660c312992dn%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/CAChs6_%3D6zVgMyPV7i4O%2BGz4iBOnaB3jQHQQeRmmKgOJ1-9sknw%40mail.gmail.com.

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

2022-09-16 Thread Matthias Koeppe

On Thursday, September 15, 2022 at 11:57:35 PM UTC-7 seb@gmail.com 
wrote:

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

Of course. Many of us shared this position back in the days when Microsoft 
was absolutely hostile to open source and in particular to the GPL.

But it's just not applicable today. Microsoft (which GitHub is a subsidiary 
of) is the single biggest contributor to open source software.

-- 
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/867d0ba7-22e6-466e-8350-b660c312992dn%40googlegroups.com.

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

2022-09-16 Thread Jan Groenewald

Dear Karmakar,

On Fri, 16 Sept 2022 at 09:36, Karmakar Subroto 
wrote:

> I don't want this email more..please removed me from your mailing
> schedule.
>

At the bottom of each email it says:

 --
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
.*

Can you do that please?

Regards,
Jan



-- 
  .~.
  /V\ Jan Groenewald
 /( )\www.aims.ac.za
 ^^-^^

-- 
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/CAAg%3Dp_0gA0pEj_0QDvj--NgdkWY2TqLub86wbW8bBy7wPBM02Q%40mail.gmail.com.

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

2022-09-16 Thread Karmakar Subroto

I don't want this email more..please removed me from your mailing schedule.

On Fri, Sep 16, 2022, 12:57 PM seb@gmail.com 
wrote:

> Matthias Koeppe schrieb am Donnerstag, 15. September 2022 um 21:22:25
> UTC+2:
>
>> On Thursday, September 15, 2022 at 2:09:23 AM UTC-7 Samuel Lelievre wrote:
>>
>>> c. Several people refuse to open a GitHub account
>>
>>
>> I don't know anyone who does. I think they should speak up for themselves
>> (unless they also refuse to participate in this list hosted on Google) so
>> we can understand what their concern is.
>>
>>
>>
>
> Potentially, I'm that kind of person and I think it is very important that
> Samuel posted these points!
>
> About ten years before Google was on Earth someone put a poster on our
> corridor of the University building: *Microsoft free area*. We all were
> proud about that. But at that point nobody knew what should come later on.
>
> In the 80ties Germany planned a nationwide census to happen once in a
> decade. I joined the resistance against it. From today's point of view this
> is absolutely ridiculous. Each day people sell much more sensitive data to
> many powerful companies and it is much less clear how they deal with your
> data.
>
> It has become really hard to refuse all the things you would like to and
> you are forced to make exceptions. Until Corona I refused to use a
> smartphone. Now I use my employer's iPhone. But I use it less than 2
> minutes a day (most of that 2FA and just WiFi).
>
> The principal question is: What is worth making an exception? I think Sage
> is worth it!
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/f1ba1b29-6fda-4873-8e44-c0a4b117e52an%40googlegroups.com
> 
> .
>

-- 
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/CAMCxhwWq82Q10_K3fcM27ubgReUzQtJ0AGry1q%2BavHb%2B-iOQMA%40mail.gmail.com.

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

2022-09-16 Thread seb....@gmail.com

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

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

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

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

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

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f1ba1b29-6fda-4873-8e44-c0a4b117e52an%40googlegroups.com.

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

2022-09-16 Thread seb....@gmail.com

Thank you both!

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/97302f85-b937-4859-815d-85092eb3596fn%40googlegroups.com.

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

On Thursday, September 15, 2022 at 2:09:23 AM UTC-7 Samuel Lelievre wrote:

> c. Several people refuse to open a GitHub account 

 
I don't know anyone who does. I think they should speak up for themselves 
(unless they also refuse to participate in this list hosted on Google) so 
we can understand what their concern is.

 

-- 
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/ad4708ac-9794-4cb4-a0a7-e524abb81095n%40googlegroups.com.

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

On Thursday, September 15, 2022 at 2:09:23 AM UTC-7 Samuel Lelievre wrote:

> I would like to voice serious objections to this move. 
>
> To me, moving to a GitHub-centric development contradicts 
> the inclusiveness and openness of the SageMath project.
>

If you really think our project is doing well on inclusivity and openness, 
look at https://github.com/sagemath/sage/graphs/contributors and think 
again.

The move to GitHub actually is a necessary critical step to *improve* 
inclusivity -- it remove barriers for attracting & retaining developers. 
Trac is a major barrier. 
The Sage wiki, excluding everyone except developers with legacy Trac 
accounts, is another one.

-- 
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/f3b9323f-18a3-42d7-b514-55329613c6d8n%40googlegroups.com.

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

On Thu, 15 Sep 2022, 15:53 William Stein,  wrote:

> On Thu, Sep 15, 2022 at 2:17 AM Samuel Lelièvre
>  wrote:
> > Increasingly, services such as GitHub and Google require
> > users to have a mobile phone number, to share it with them,
> > and to be able to receive text messages on them in order
> > to be able to log in or access certain features.


>
> I don't think this is the case of GitHub right now.   They do
> optionally *support* 2-factor authentication (unlike our trac setup),
> which is a very (very!) good thing from a security point of view.
> Personally, I enable 2-factor for GitHub and use a generic 2-factor
> app on my phone.


one does not need a phone for 2FA; a software solution such as one of these
Authenticators (Google or other) can be replaced by a command line one.
It's available on most Linux distros, on Homebrew, etc. E.g. on Debian
https://packages.debian.org/bookworm/pass-otp

The setup normally involves a (private - but I guess it's not necessary due
to encryption) git repo
to store your passwords and 2FA data, so you can pull from/push to this
repo from any machine you are
using. This data is encrypted with you gpg key, no it's not out in the wild.

With this in place one runs, at the shell one runs something like

pass otp gh

to get the 2FA code for Github.

There are also hardware solutions:
https://fidoalliance.org/fido2/
which means you need to get a little token which plugs into a USB port (or
there are also wireless variants)
and serves as authenticator for 2FA, the most well-known seems to be ones
made by yubiko:
https://www.yubico.com/



> Maybe we should require 2-factor? [1]
>

I think we should. And moreover we need to consider extra measures to
secure git commits,
namely gpg-signing of the commits (indeed, one can also sneak bad code
directly via git, bypassing anything else).

Dima



> I would not dismiss your concern about GitHub eventually charging as
> easily as Dima did.  In fact, just two days ago
> GitLab (not GitHub) noticeably cracked down on free usage
>
> https://news.ycombinator.com/item?id=32821682
>
> That said, on GitLab open source projects such as SageMath would still
> be free, as they have a special application process for open source
> projects.   It is also supposed to be easy to migrate complete
> projects from GitHub to GitLab if necessary, as that's a key part of
> GitLab's business model.
>
> There is no requirement that all hosting for everything involving
> SageMath be completely free. [2]
>
> My personal biggest fear with GitHub was for a long time "What happens
> when they get bought by big-company-X?".  At least that was answered
> when Microsoft bought them in 2018 (see [3]); at least now they won't
> be bought by Oracle (I painfully remember Oracle killing Sun
> Microsofts literally months after SageMath started getting some
> *major* marketing and vendor support from Sun.)
>
>  -- William
>
> [1] Related to this, the JupyterLab project this week flipped a switch
> to *require* all developers with commit access to use 2-factor
> authentication.  We don't have to make that requirement for SageMath,
> though personally I think we should, since if a hacker were to break
> into one person's account and sneak bad code into Sage, it could be
> very bad (for whoever it targets, and also for our reputation).  Due
> to Sage's use in cryptography research, there are very good arguments
> that Sage would be a high value target for such attacks, e.g., by
> sophisticated state sponsored entities.
>
>
> [2]  E.g., I guess we've been paying to host trac much more than we
> would pay for GitHub if it weren't free.
>
> [3] https://news.microsoft.com/announcement/microsoft-acquires-github/
>
> --
> William (http://wstein.org)
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/CACLE5GCg6cwXhXDVwrJGNufu8%2BYVscZDtFjCu-wpX-N9YDO-7Q%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/CAAWYfq22-5NK2epGVLjqgN94m5pv1EYArMUTte%3DmSpgefX4fkw%40mail.gmail.com.

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

On Thursday, September 15, 2022 at 9:04:09 AM UTC-7 Matthias Koeppe wrote:

> On Thursday, September 15, 2022 at 6:21:09 AM UTC-7 Eric Gourgoulhon wrote:
>
>> I don't understand why in the post
>> https://groups.google.com/g/sage-devel/c/QooOF1GLMOs
>> Matthias asked to remove developer names from 
>> (1) https://trac.sagemath.org/#AccountNamesMappedtoRealNames
>> Aren't we loosing information here?
>> I of course understand there is now 
>> https://github.com/sagemath/website/blob/master/conf/contributors.xml
>> and that duplication is the root of all evil, but if a read-only mirror 
>> of Trac is maintained, the list (1) would be useful to contact a Sage 
>> developer regarding a specific ticket. 
>>
>
> No, the data is not lost. It is *migrated* to 
> https://github.com/sagemath/website/blob/master/conf/contributors.xml, 
> where it will be preserved (including the Trac usernames).
>

To add to this: The purpose of my request to remove your info after merging 
it into contributors.xml is the following:
In 2 weeks or so, I'll bulk-merge the remaining info into contributors.xml; 
and I will do a cursory review of each item. 
By removing your already-merged data from the source, you'll save me the 
time to check which of the information (in contributors.xml or Trac) is 
more current.

-- 
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/48947290-867b-422a-aa8e-ecd2bfb38d8cn%40googlegroups.com.

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

On Thursday, September 15, 2022 at 2:09:23 AM UTC-7 Samuel Lelievre wrote:

> d. Moving to GitHub because a lot of software development 
> has moved there does not seem a relevant argument to me.

No, Samuel, this comment trivializes what has been said regarding the 
benefits of a big network.

The scale of it really matters. 

Not only are there network effects between open source projects. Because of 
its dominance, virtually every potential new developer is familiar and 
skilled with GitHub. Talk to any young people. They have been growing up 
with GitHub. Students use it for their homework projects, for their hobby 
projects, everything. Moving to GitHub completely eliminates the current 
friction with making a first contribution to Sage. Spot a typo, fix it? 
It's done in 30 seconds total. No reading of our developer's guide is 
needed, no navigating of an obscure system that looks & feels like 
something from their computing history class.

-- 
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/559d8cb8-83b6-407a-94a7-ae685a9db5a9n%40googlegroups.com.

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

On Wednesday, September 14, 2022 at 11:40:12 PM UTC-7 seb@gmail.com 
wrote:

> What is the proposed workflow to merge the develop branch after a new 
> release into PR (or other) branches of your fork (i.e re-basing)? Obviously 
> this is possible by pushing on sync in the web interface or typing gh 
> repo sync USERNAME/sage -b branch in the command line. But how do you 
> resolve conflicts?
>
Like Dima explained, all of the PR syncing is just additional convenience. 
You can continue to just do all merging on your computer using the very 
same git commands and just push the updated branch to your repo. It will 
then be automatically reflected in the PR.
 

> If a PR is linked to the Issue, you can alternatively comment on the PR.
>
> It sounds like wasting time by searching for comments. Can’t we define a 
> preference here? This seems to be a part of the decentralized structure 
> that Travis is criticizing.
>
In actual practice, this is a non-problem, it is obvious where a comment 
should go. 
And in fact, also on Trac we often have overlapping discussions in related 
tickets, and Sage developers have been able to navigate this quite well.
But yes, we can provide explicit guidance to Sage developers. I've added a 
few bits 
to https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b in 
this direction. Help is welcome in expanding this.



-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3d845614-e22b-4a0d-bb6a-66b5b4a74d98n%40googlegroups.com.

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

On Thursday, September 15, 2022 at 6:21:09 AM UTC-7 Eric Gourgoulhon wrote:

> I don't understand why in the post
> https://groups.google.com/g/sage-devel/c/QooOF1GLMOs
> Matthias asked to remove developer names from 
> (1) https://trac.sagemath.org/#AccountNamesMappedtoRealNames
> Aren't we loosing information here?
> I of course understand there is now 
> https://github.com/sagemath/website/blob/master/conf/contributors.xml
> and that duplication is the root of all evil, but if a read-only mirror of 
> Trac is maintained, the list (1) would be useful to contact a Sage 
> developer regarding a specific ticket. 
>

No, the data is not lost. It is *migrated* to 
https://github.com/sagemath/website/blob/master/conf/contributors.xml, 
where it will be preserved (including the Trac usernames).

-- 
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/ac670558-5af3-4a3e-a172-08185ce99db9n%40googlegroups.com.

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

2022-09-15 Thread William Stein

On Thu, Sep 15, 2022 at 2:17 AM Samuel Lelièvre
wrote:
> Increasingly, services such as GitHub and Google require
> users to have a mobile phone number, to share it with them,
> and to be able to receive text messages on them in order
> to be able to log in or access certain features.

I don't think this is the case of GitHub right now. They do
optionally *support* 2-factor authentication (unlike our trac setup),
which is a very (very!) good thing from a security point of view.
Personally, I enable 2-factor for GitHub and use a generic 2-factor
app on my phone. Maybe we should require 2-factor? [1]

I would not dismiss your concern about GitHub eventually charging as
easily as Dima did. In fact, just two days ago
GitLab (not GitHub) noticeably cracked down on free usage

https://news.ycombinator.com/item?id=32821682

That said, on GitLab open source projects such as SageMath would still
be free, as they have a special application process for open source
projects. It is also supposed to be easy to migrate complete
projects from GitHub to GitLab if necessary, as that's a key part of
GitLab's business model.

There is no requirement that all hosting for everything involving
SageMath be completely free. [2]

My personal biggest fear with GitHub was for a long time "What happens
when they get bought by big-company-X?". At least that was answered
when Microsoft bought them in 2018 (see [3]); at least now they won't
be bought by Oracle (I painfully remember Oracle killing Sun
Microsofts literally months after SageMath started getting some
*major* marketing and vendor support from Sun.)

-- William

[1] Related to this, the JupyterLab project this week flipped a switch
to *require* all developers with commit access to use 2-factor
authentication. We don't have to make that requirement for SageMath,
though personally I think we should, since if a hacker were to break
into one person's account and sneak bad code into Sage, it could be
very bad (for whoever it targets, and also for our reputation). Due
to Sage's use in cryptography research, there are very good arguments
that Sage would be a high value target for such attacks, e.g., by
sophisticated state sponsored entities.

[2] E.g., I guess we've been paying to host trac much more than we
would pay for GitHub if it weren't free.

[3] https://news.microsoft.com/announcement/microsoft-acquires-github/

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

--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CACLE5GCg6cwXhXDVwrJGNufu8%2BYVscZDtFjCu-wpX-N9YDO-7Q%40mail.gmail.com.

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

On Thu, Sep 15, 2022 at 2:47 PM Eric Gourgoulhon  wrote:
>
> Le jeudi 15 septembre 2022 à 15:32:22 UTC+2, dim...@gmail.com a écrit :
>>
>>
>>
>> On Thu, 15 Sep 2022, 14:21 Eric Gourgoulhon,  wrote:
>>>
>>> I would like to ask about a point that does not seem to have been discussed 
>>> before (apologies if it was):
>>> If the migration to Gihub takes place, would there remain somewhere a 
>>> read-only copy of Trac? more precisely, of all the Trac tickets?
>>
>>
>> yes, this is the plan, to migrate all trac tickets to GitHub issues. There 
>> are some technical issues involving issues getting correct (i.e. correctly 
>> mapped to GitHub accounts) authors, hopefully resolved with help of GitHub 
>> support,
>> but apart from this we are not too far getting the migration done. (the git 
>> tree is there on a github mirror repo, so links to branches will be pointing 
>> there). Attachments will be imported and hosted somewhere, too.
>>
>> a read-only copy of trac will be around for a while, to make sure it all 
>> went well, but I don't expect a strong need to keep it forever.
>>
>
>  Thanks for your prompt answer.
>
>> what's not clear there?
>>
>
> The description of
> https://github.com/sagemath/trac-to-github
> says
> "This script migrates milestones, issues, and wiki pages from Trac to GitHub."
> What about tickets?

OK, thanks, I clarified this now.
>
> Your answer made it more clear. Thanks.
>
> Eric.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/134ab1cc-2569-47d0-b57d-8aa81be492fen%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/CAAWYfq0WQ%2BeM99e3F2Yufs9t-BDwr9UkaWTj8Pq4WafEMgrUkw%40mail.gmail.com.

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

2022-09-15 Thread Eric Gourgoulhon

Le jeudi 15 septembre 2022 à 15:32:22 UTC+2, dim...@gmail.com a écrit :

>
>
> On Thu, 15 Sep 2022, 14:21 Eric Gourgoulhon,  wrote:
>
>> I would like to ask about a point that does not seem to have been 
>> discussed before (apologies if it was):
>> If the migration to Gihub takes place, would there remain somewhere a 
>> read-only copy of Trac? more precisely, of all the Trac tickets? 
>>
>
> yes, this is the plan, to migrate all trac tickets to GitHub issues. There 
> are some technical issues involving issues getting correct (i.e. correctly 
> mapped to GitHub accounts) authors, hopefully resolved with help of GitHub 
> support,
> but apart from this we are not too far getting the migration done. (the 
> git tree is there on a github mirror repo, so links to branches will be 
> pointing there). Attachments will be imported and hosted somewhere, too.
>
> a read-only copy of trac will be around for a while, to make sure it all 
> went well, but I don't expect a strong need to keep it forever.
>
>
 Thanks for your prompt answer.

what's not clear there?
>
>
The description of 
https://github.com/sagemath/trac-to-github
says
"This script migrates milestones, issues, and wiki pages from Trac to 
GitHub."
What about tickets?

Your answer made it more clear. Thanks. 

Eric. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/134ab1cc-2569-47d0-b57d-8aa81be492fen%40googlegroups.com.

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

On Thu, 15 Sep 2022, 14:21 Eric Gourgoulhon,  wrote:

> I would like to ask about a point that does not seem to have been
> discussed before (apologies if it was):
> If the migration to Gihub takes place, would there remain somewhere a
> read-only copy of Trac? more precisely, of all the Trac tickets?
>

yes, this is the plan, to migrate all trac tickets to GitHub issues. There
are some technical issues involving issues getting correct (i.e. correctly
mapped to GitHub accounts) authors, hopefully resolved with help of GitHub
support,
but apart from this we are not too far getting the migration done. (the git
tree is there on a github mirror repo, so links to branches will be
pointing there). Attachments will be imported and hosted somewhere, too.

a read-only copy of trac will be around for a while, to make sure it all
went well, but I don't expect a strong need to keep it forever.


The numerous discussions there constitute a valuable database, certainly
> useful for future Sage code development.
> In this respect, I don't understand why in the post
> https://groups.google.com/g/sage-devel/c/QooOF1GLMOs
> Matthias asked to remove developer names from
> (1) https://trac.sagemath.org/#AccountNamesMappedtoRealNames
> Aren't we loosing information here?
> I of course understand there is now
> https://github.com/sagemath/website/blob/master/conf/contributors.xml
> and that duplication is the root of all evil, but if a read-only mirror of
> Trac is maintained, the list (1) would be useful to contact a Sage
> developer regarding a specific ticket.
>
> There is mention of "conversion of Trac tickets and the Trac wiki to
> Github" at
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
> which might cover the point raised above, but this is not clear to me.
>

what's not clear there?

Dima


> Eric.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/9f76d868-d5fe-4219-b1f8-829af95c6c07n%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/CAAWYfq1CMNk7VYK%3DVJqeQfj9QUKyS5XZrgihK%2BPsnpRuJZizAg%40mail.gmail.com.

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

2022-09-15 Thread Eric Gourgoulhon

I would like to ask about a point that does not seem to have been discussed
before (apologies if it was):
If the migration to Gihub takes place, would there remain somewhere a
read-only copy of Trac? more precisely, of all the Trac tickets? The
numerous discussions there constitute a valuable database, certainly useful
for future Sage code development.
In this respect, I don't understand why in the post
https://groups.google.com/g/sage-devel/c/QooOF1GLMOs
Matthias asked to remove developer names from
(1) https://trac.sagemath.org/#AccountNamesMappedtoRealNames
Aren't we loosing information here?
I of course understand there is now
https://github.com/sagemath/website/blob/master/conf/contributors.xml
and that duplication is the root of all evil, but if a read-only mirror of
Trac is maintained, the list (1) would be useful to contact a Sage
developer regarding a specific ticket.

There is mention of "conversion of Trac tickets and the Trac wiki to
Github" at
https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
which might cover the point raised above, but this is not clear to me.

Eric.

--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/9f76d868-d5fe-4219-b1f8-829af95c6c07n%40googlegroups.com.

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

On Thu, Sep 15, 2022 at 10:17 AM Samuel Lelièvre
 wrote:
>
> One more thought.
>
> Increasingly, services such as GitHub and Google require
> users to have a mobile phone number, to share it with them,
> and to be able to receive text messages on them in order
> to be able to log in or access certain features.

GitHub does not *require* a mobile phone, for anything at all, including
their 2FA.

>
> I do not think contributing to Sage should require people to
> have a mobile phone or to give their mobile phone number
> to big tech companies such as GAFAM, or to always be
> able to receive text messages.

as if big companies don't know your mobile number - you're using gmail
yourself, right...
Anyhow, no, even if you're one of extremely lucky and privileged few
who can live in 2022 in a developed country
without a mobile, you still can use GitHub, sorry :-)

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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAEcArF2oHpXgsZchfVOrj3pWr-7g8%2B%2BZ%3DAXnyMcqFPzzohCqUQ%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/CAAWYfq2NRQC2qrKjbKxQcKaM7A%2ByR_PtqtDL84-WSAL8ojMpug%40mail.gmail.com.

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

On Thu, Sep 15, 2022 at 10:09 AM Samuel Lelièvre
 wrote:
>
> On Friday, 09 Sep 2022, 09:54 UTC, Dima Pasechnik wrote:
> >
> > I am resurrecting this thread, as in addition of trac continuing to eat up 
> > funds
> > (at a rate of over US$ 10 per day at the moment), it has gotten increasingly
> > broken. In particular, in the last 2 weeks no new developers can really join
> > the project, as there is no normal* way to add new ssh keys into trac 
> > accounts,
> > and it's not possible to push/pull with "new" github ssh keys, i.e. keys 
> > that
> > were not already "known" to trac, i.e. added to the trac store of ssh keys
> > before the last breakage happened.
> >
> > As far as funding is concerned, attempts to bring trac to a "free" hosting
> > stalled (see earlier messages in this thread).
> >
> > A further longer term issue is that trac software is basically on life 
> > support,
> > and it's only matter of time it will become totally obsolete.
> >
> > Such a move will allow a considerable simplification of our devops,
> > and free up quite a bit of developer time
> > to do interesting work rather than messing around with semi-obsolete
> > stuff such as trac, gitolite, etc.
> >
> > Importantly, Volker, the release manager, is willing to proceed with the 
> > move.
> >
> > Also, various Sage upstream (and downstream) projects have moved
> > away from trac to github, e.g. Cython, or away from another system
> > to github, e.g. CPython, GAP, jupyter, etc...
> >
> > There is a trac ticket to manage the proposed move,
> > https://trac.sagemath.org/ticket/30363 tentatively set for Sage 9.8.
> >
> > I've conducted few experiments with a tool to import trac sites to github:
> > https://github.com/svigerske/trac-to-github, which in particular allows
> > to import trac tickets as github issues; a result of running it on few 
> > tickets
> > may be inspected here:
> > https://github.com/dimpase/trac_to_gh/issues?q=is%3Aissue+is%3Aclosed
> > (Here issues 1-10 correspond to trac tickets one to one :-))
> > Further work on trac-to-github will be needed, in particular to properly
> > link branches in our git tree, but it's doable,
> > and we have volunteers to do it.
> >
> > We'd like to hear about serious objections to the move, if any.
>
> I would like to voice serious objections to this move.

Samuel,

What you describe are all purely imaginary for us problems, and surely
much bigger
open source projects such as Python, llvm, etc., which moved to
GitHub, thought long and hard
about moving (or not). Yet they did. By association you accuse them of
being non-inclusive,
etc. Maybe we shoud move away from Python and stop using llvm/clang too?

You have no issue with us paying real money to Google, which is much
more evil than GitHub,
no doubt about it. And you are a long term macOS/Apple user, paying
money to a company which blocks
developers, users, etc all the time, in much more aggressive than
GitHub way - it's basically leeching on
independent macOS developers, charging rudiclous percentage for
transactions on their AppStore,
or whatever it's called ...

No, really, let's stop pretending we're so inclusive and open and not
relying in any way on
big commercial companies - which sometimes need to adhere to
legalisations (apart from them
acting out of self interest).

>
> To me, moving to a GitHub-centric development contradicts
> the inclusiveness and openness of the SageMath project.
>
> a. The company operating GitHub can block access to GitHub,
> block account creation, or terminate accounts for individuals,
> companies or countries without prior notice on discriminatory
> grounds, see links below.

I spend some time reading [GitHub controversies] link. I must say,
worrying about a single, and settled, employee harassment case,
and other links actually show that while they sometimes overreact (who
doesn't), they
normally quickly correct themselves.
Strikes me as very, very unimpressive, if you compare this e.g.
with Google's rasist ML models scandal...

>
> b. Relying on free software tools for essential infrastructure
> is something I value a lot in the Sage project. Trac is that,
> GitHub is not.

Google cloud is not free software, either, yet you keep using it...

>
> c. Several people refuse to open a GitHub account and are
> much more comfortable contributing to Sage using a Trac
> account on our Trac server.

It reminds me of people who refuse to use bank cards, and only use cash...
Objections against opening a GitHub account are mosly pure paranoia
(or pure politics),
because all you need is an email address. Get a dedicated email for
this task only, if you must.

>
> d. Moving to GitHub because a lot of software development
> has moved there does not seem a relevant argument to me.

How it's not relevant? Surery in your permanent employment ivory tower
you might not care
about getting useful, in real non-academic life, skills.

>
> e. Today GitHub exists. Tomorrow it might shut down.
> Gitorious, Google

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

2022-09-15 Thread Samuel Lelièvre

One more thought.

Increasingly, services such as GitHub and Google require
users to have a mobile phone number, to share it with them,
and to be able to receive text messages on them in order
to be able to log in or access certain features.

I do not think contributing to Sage should require people to
have a mobile phone or to give their mobile phone number
to big tech companies such as GAFAM, or to always be
able to receive text messages.

-- 
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/CAEcArF2oHpXgsZchfVOrj3pWr-7g8%2B%2BZ%3DAXnyMcqFPzzohCqUQ%40mail.gmail.com.

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

2022-09-15 Thread Samuel Lelièvre

On Friday, 09 Sep 2022, 09:54 UTC, Dima Pasechnik wrote:
>
> I am resurrecting this thread, as in addition of trac continuing to eat up 
> funds
> (at a rate of over US$ 10 per day at the moment), it has gotten increasingly
> broken. In particular, in the last 2 weeks no new developers can really join
> the project, as there is no normal* way to add new ssh keys into trac 
> accounts,
> and it's not possible to push/pull with "new" github ssh keys, i.e. keys that
> were not already "known" to trac, i.e. added to the trac store of ssh keys
> before the last breakage happened.
>
> As far as funding is concerned, attempts to bring trac to a "free" hosting
> stalled (see earlier messages in this thread).
>
> A further longer term issue is that trac software is basically on life 
> support,
> and it's only matter of time it will become totally obsolete.
>
> Such a move will allow a considerable simplification of our devops,
> and free up quite a bit of developer time
> to do interesting work rather than messing around with semi-obsolete
> stuff such as trac, gitolite, etc.
>
> Importantly, Volker, the release manager, is willing to proceed with the move.
>
> Also, various Sage upstream (and downstream) projects have moved
> away from trac to github, e.g. Cython, or away from another system
> to github, e.g. CPython, GAP, jupyter, etc...
>
> There is a trac ticket to manage the proposed move,
> https://trac.sagemath.org/ticket/30363 tentatively set for Sage 9.8.
>
> I've conducted few experiments with a tool to import trac sites to github:
> https://github.com/svigerske/trac-to-github, which in particular allows
> to import trac tickets as github issues; a result of running it on few tickets
> may be inspected here:
> https://github.com/dimpase/trac_to_gh/issues?q=is%3Aissue+is%3Aclosed
> (Here issues 1-10 correspond to trac tickets one to one :-))
> Further work on trac-to-github will be needed, in particular to properly
> link branches in our git tree, but it's doable,
> and we have volunteers to do it.
>
> We'd like to hear about serious objections to the move, if any.

I would like to voice serious objections to this move.

To me, moving to a GitHub-centric development contradicts
the inclusiveness and openness of the SageMath project.

a. The company operating GitHub can block access to GitHub,
block account creation, or terminate accounts for individuals,
companies or countries without prior notice on discriminatory
grounds, see links below.

b. Relying on free software tools for essential infrastructure
is something I value a lot in the Sage project. Trac is that,
GitHub is not.

c. Several people refuse to open a GitHub account and are
much more comfortable contributing to Sage using a Trac
account on our Trac server.

d. Moving to GitHub because a lot of software development
has moved there does not seem a relevant argument to me.

e. Today GitHub exists. Tomorrow it might shut down.
Gitorious, Google Code, Gna!, CodePlex and many others did.

f. Today GitHub charges no fee to free software projects.
Tomorrow that might change. Remember how Travis CI
was once free for free software projects, then no longer.

My experience is that using Trac as our main public repository
and issue tracker works well, and does not prevent us from
using other tools in addition.

- Merge requests against the SageMath repository at GitLab
  are turned into Trac tickets automatically. As far as I know
  this works well and developers of p-adic functionality use it
  quite a lot.

- There used to be a similar mechanism to turn pull requests
  against the SageMath repository on GitHub into Trac tickets.
  From what I understand it was not extremely complex and
  someone with the right skills could hopefully revive it. See

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

- We are able to use GitHub Actions and to integrate them
  with our Trac server, with badges displaying the result of
  these automated actions displayed on each ticket.

Hosting our Trac server at Google seems to be a problem.
I can ask my department about hosting Trac. Can someone
summarize the requirements (disk space, RAM, etc.)?

Kind regards,  --Samuel

--- Some links about GitHub policies and controversies ---

GitHub and US trade controls
https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls

GitHub controversies
https://en.wikipedia.org/wiki/GitHub#Controversies

GitHub has suspended my account for no reason
https://padida-ali.medium.com/github-has-suspended-my-account-for-no-reason-99ebbcad98cc

GitHub blocks entire company because one employee was in Iran
https://news.ycombinator.com/item?id=25644056

Microsoft enters: GitHub banned Iranian developers!
https://medium.com/@devengine/microsoft-enters-github-banned-iranian-developers-843f7c60a146

-- 
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

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

On Thu, 15 Sep 2022, 07:40 seb@gmail.com,  wrote:

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

I am not sure how resolving conflicts is in any way different from trac. At
least on the level of plain git it is just the same.

If you have a branch in your repo fork, which is a PR, pushing (with gh, or
plain git, or whatever) into this branch (after you resolved conflicts and
commited the result, naturally) will update the PR automatically.


If a PR is linked to the Issue, you can alternatively comment on the PR.
>
> It sounds like wasting time by searching for comments. Can’t we define a
> preference here? This seems to be a part of the decentralized structure
> that Travis is criticizing.
>
there are pluses too - you don't want technical comments on the code to
clog the real picture.

Besides, there are very nice code review tools there built in PR handling -
compared to them trac is very inefficient.



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

> My understanding from the 
> allowing-changes-to-a-pull-request-branch-created-from-a-fork
> documentation
> 
>  is
> that only users who have push permission on the repository will be able to
> make edits to a pull request.  I think the consequence is that we want
> active Sage developers to have Write access
> 
> to the repository, and then use branch protection rules
> 
> on develop and master.
>
>>
>>
 Yes, please take a look at
 https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-permissions-and-protections,
 where I have started to write something like this.



>>> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/ae0f1f0f-f68a-4169-8c5b-6b66a2937fc9n%40googlegroups.com
> 
> .
>

-- 
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/CAAWYfq25r1dSwkYYS%2Bz2VmppKfT%3D9UQyOso28xT74cFmKUHW-w%40mail.gmail.com.

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

2022-09-15 Thread seb....@gmail.com



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

BTW: I’m not sure I like this!

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

It sounds like wasting time by searching for comments. Can’t we define a 
preference here? This seems to be a part of the decentralized structure 
that Travis is criticizing.

Matthias Koeppe schrieb am Mittwoch, 14. September 2022 um 23:19:28 UTC+2:

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

>
>
>>> Yes, please take a look at 
>>> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-permissions-and-protections,
>>>  
>>> where I have started to write something like this.
>>>
>>>  
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ae0f1f0f-f68a-4169-8c5b-6b66a2937fc9n%40googlegroups.com.

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

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

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] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

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

2022-09-14 Thread 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] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

2022-09-14 Thread 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

2022-09-14 Thread 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

2022-09-14 Thread 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

2022-09-14 Thread 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

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.

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

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/e6e7b3cf-7ceb-4a2a-9b7b-587dd41ef172n%40googlegroups.com.

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

2022-09-13 Thread David Roe

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.

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 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+unsubscr...@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+unsubscr...@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/CAChs6_kDgLwPyg1p034SbNrUseNzcJj3MHVNPKUO_5jrrVEGsQ%40mail.gmail.com.

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

2022-09-13 Thread Nils Bruin

On Tuesday, 13 September 2022 at 19:43:32 UTC-7 Matthias Koeppe wrote:

> On Tuesday, September 13, 2022 at 7:15:10 PM UTC-7 Nils Bruin wrote:
>
>> 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.
>>
>
> 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.

There is of course a "git" way of doing it: make a fork on github and add 
collaborators to that "project". Then all those people can push to their 
heart's content to the forked repo and it's their responsibility of keeping 
their branches sane. But setting that up is *way* heavier than the organic 
"git trac push".

One advantage we got from git-trac was that people have *limited* push 
privileges: they can only push to branches that they "own". The worst that 
I could mess up a ticket is by linking the wrong branch to a ticket. But 
since the original branch still exists, with a name, this is easily undone. 
So it struck a nice balance, at the cost of an in principle unreliable 
branch link on tickets, because pretty much anyone with trac access can 
change that. However, those changes are well visible and not anonymous and 
haven't been a problem.

So it looks like the git plugin to trac provides a rather stringent form of 
"branch protection" that could be nice to have on github as 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5311cc84-7751-4eef-bf57-5bce5651b21dn%40googlegroups.com.

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

2022-09-13 Thread David Roe

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.
David

On Tue, Sep 13, 2022 at 10:46 PM Matthias Koeppe 
wrote:

> On Tuesday, September 13, 2022 at 7:15:10 PM UTC-7 Nils Bruin wrote:
>
>>
>> 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.
>>
>
> Yes, we should add some detail about this to
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-workflow-on-github-with-transition-guide-from-trac
>
> A related question is regarding roles for developers and permissions in
> our main repository. That's something in the document that still needs to
> be fleshed out (
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-permissions-and-protections).
> Any help / discussion of this is very welcome.
>
>
>
> --
> 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/2c9d8ce6-315b-415c-96d2-a47e89949456n%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/CAChs6_kUkQZHSACf052yHsLKP9kA02w9yfopViReqSrTS3wJFA%40mail.gmail.com.

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

On Tuesday, September 13, 2022 at 2:33:07 AM UTC-7 tobias...@gmail.com 
wrote:

> 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 user proposing a new feature or reporting a bug. This is 
> reflected in that the discussion in an issue is largely on a meta-level. 
> For example, discussing whether the proposed feature is actually needed or 
> fit into the roadmap of the project; or for bugs outline how it can be 
> reproduced. Discussions in pull requests on the other hand revolve more 
> around the proposed implementation, code style and other such feedback.
>

I have added a bit that acknowledges the fact that there are separate 
comment threads for Issue & linked PR 
to https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
If it makes sense, we can add additional guidance along your explanation 
above. But I don't think this needs much clarification.
 

-- 
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/6d591ebd-32a5-402e-a337-a7583699440fn%40googlegroups.com.

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

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

> On Tuesday, 13 September 2022 at 14:04:24 UTC-7 dim...@gmail.com wrote:
>
>> 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"
>

I've added this now, thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3cc4ac28-c925-4567-96a2-3b732e63ca0en%40googlegroups.com.

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

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

>
> 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.
>

Yes, we should add some detail about this 
to 
https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-workflow-on-github-with-transition-guide-from-trac

A related question is regarding roles for developers and permissions in our 
main repository. That's something in the document that still needs to be 
fleshed out 
(https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-permissions-and-protections).
 
Any help / discussion of this is very welcome.

 

-- 
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/2c9d8ce6-315b-415c-96d2-a47e89949456n%40googlegroups.com.

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

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

> 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.
>

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.

-- 
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/eee44d79-d7a6-44f6-8306-c7e7058e7b8cn%40googlegroups.com.

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

2022-09-13 Thread Nils Bruin

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/e0a37229-9a65-40f5-aad0-106a42e6242fn%40googlegroups.com.

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

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.

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.


>
>
>
>
> --
> 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/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+unsubscr...@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.

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

On Tuesday, September 13, 2022 at 3:01:14 PM UTC-7 Thierry 
(sage-googlesucks@xxx) wrote:

> given the conditions and how they affect my mental health,
>

Taking care of one's mental health is very important, and I do hope that 
you'll be able to cope.
It is an individual's responsibility to take care of themselves and seek 
help where it is needed.
Holding other people or circumstances responsible is not usually not a 
healthy approach.

Take care,
Matthias

-- 
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/f7c92211-eb79-4b85-ac6a-77d747e33cf2n%40googlegroups.com.

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

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.





-- 
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/aaf7b1d7-747d-4318-974b-c8ea9e150d42n%40googlegroups.com.

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

2022-09-13 Thread Thierry

Hi,

On Tue, Sep 13, 2022 at 01:30:05AM -0400, David Roe wrote:
> While I strongly support the shift to github, I also agree with Travis that
> we should vote on a change this major, and give the community enough time
> to weigh in.  I would also encourage people on both sides of the debate to
> give everyone the benefit of the doubt.  To those who have been putting in
> a ton of work attempting to fix trac in recent weeks, our broken
> infrastructure is both frustrating and gives a sense of urgency.  To those
> who have spent over a decade using trac, the most recent iteration of this
> discussion (starting four days ago) feels very rushed.
> 
> Here's a proposal on a timeline for making a decision (I welcome feedback
> from anyone who thinks this is too fast or too slow).
> 
> * We spend another few days discussing pros and cons and refining the
> proposed workflows.


The academic year is starting (at least in France), people are already
very busy with all sort of administrative things. I personally have to
attend a conference next week and my PhD student is going to defend in
the beginning of October.

Also, several people have already explicitely requested for a break (if
not a truce, given the level of agressivity).

I would like to contribute to the important question of the evolution of
our development tools, but given the conditions and how they affect my
mental health, as for me, one month break is a bare minimum. Blitzkrieg,
state of emergency, false dilemma, and policy of fait accompli can not
be part of a healthy decision-making.

Ciao,
Thierry





> * I'll volunteer to collate the arguments that have been made into a list
> of pros and cons together with a concrete proposal, and we can send out an
> email in a separate thread announcing a vote later this week.
> * The deadline for voting will be one week from the announcement (so, late
> next week).
> * If the consensus of the community is to switch to github, then a smaller
> group can proceed with implementation (I'm also willing to be involved in
> that effort).
> David
> 
> On Tue, Sep 13, 2022 at 1:13 AM 'Travis Scrimshaw' via sage-devel <
> sage-devel@googlegroups.com> wrote:
> 
> >
> >> But people nowadays who start with GitHub never have to go through
>  archaic setup steps such as those that we document at
>  https://doc.sagemath.org/html/en/developer/trac.html#trac-authentication-through-ssh,
>  which --- even when it is working --- is major friction for the project.
> 
> >>>
> >>> I think it has been just far too long since you uploaded your ssh key to
> >>> GH. The server cannot magically know your ssh public key.
> >>>
> >>
> >> You are missing that the new contributors will already have set up their
> >> GitHub for virtual everything else that they work on. There is no
> >> additional such cost for starting to work on a new project that's also
> >> hosted on GitHub.
> >> This is a just tiny bit of the big network effects that will come.
> >>
> >
> > This is true, they do have to do it for our separate project. However,
> > your characterization that the current setup is archaic is false unless you
> > want to call what GH does archaic too. I also don't agree that it is a
> > major friction point; all of my experience/feedback has been people have
> > the most trouble getting user names to access trac and dealing with our
> > coding/doc standards.
> >
> > --
> > 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/68256bda-39ec-473a-9afb-3f026132377en%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/CAChs6_m4jNCxwYd77XFkJQzBXGCymQNmBV9A-nEULBG_wfZj6w%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/20220913220110.GA26414%40metelu.net.

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

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.


> Note that sage trees are rather voluminous, so (some?) people tend to have
> not that many of them on their machine.
>

indeed, and it would not change. no need for extra trees, compared to trac
workflow.

If you're working on tickets that are relatively close to the current
> develop, it's quite doable to just check them in/out as you switch your
> work. I don't know how that would work if one needs multiple remotes.
>
> On Tuesday, 13 September 2022 at 01:03:59 UTC-7 Matthias Koeppe wrote:
>
>> On Tuesday, September 13, 2022 at 12:57:47 AM UTC-7 Travis Scrimshaw
>> wrote:
>>
>>> With our current setup, I could push the branch to the server, email you
>>> the branch name, and you could pull it.
>>>
>>
>> So you're discussing a use case of the trac git server to share a branch
>> that has nothing to do with a trac ticket.
>> Doesn't sound like anything that needs a solution.
>>
>>
>>
> --
> 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/a1e125fb-1f91-48c1-bf2e-aa675502528an%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/CAAWYfq3ZEo1GvELPhVWnm4tR%2BBe_vbqAAS%2B5DvWcWaT5mf2OgQ%40mail.gmail.com.

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

2022-09-13 Thread Nils Bruin

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.

Note that sage trees are rather voluminous, so (some?) people tend to have 
not that many of them on their machine. If you're working on tickets that 
are relatively close to the current develop, it's quite doable to just 
check them in/out as you switch your work. I don't know how that would work 
if one needs multiple remotes.

On Tuesday, 13 September 2022 at 01:03:59 UTC-7 Matthias Koeppe wrote:

> On Tuesday, September 13, 2022 at 12:57:47 AM UTC-7 Travis Scrimshaw wrote:
>
>> With our current setup, I could push the branch to the server, email you 
>> the branch name, and you could pull it.
>>
>
> So you're discussing a use case of the trac git server to share a branch 
> that has nothing to do with a trac ticket.
> Doesn't sound like anything that needs a solution.
>
>  
>

-- 
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/a1e125fb-1f91-48c1-bf2e-aa675502528an%40googlegroups.com.

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

I've added this 
to 
https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-workflow-on-github-with-transition-guide-from-trac
 
now.


On Tuesday, September 13, 2022 at 12:05:48 AM UTC-7 Travis Scrimshaw wrote:

> On Tuesday, September 13, 2022 at 3:36:18 PM UTC+9 Matthias Koeppe wrote:
>
>> On Monday, September 12, 2022 at 10:36:06 PM UTC-7 Travis Scrimshaw wrote:
>>
>>> Last I remember, using https instead of ssh meant I had to input my 
>>> UN/PW every time I did a push or a pull
>>>
>>
>>
>> https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git
>>  
>>
> I was not aware of that. I don't remember that being there when I first 
> started using git and GH (some 10+ years ago I think). Perhaps I should 
> have checked this more thoroughly. Nevertheless, good to know.
>

-- 
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/25feeefe-f957-4124-a6dc-8f2eb2142741n%40googlegroups.com.

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

On Tuesday, September 13, 2022 at 4:03:36 AM UTC-7 kcrisman wrote:

> > Consensus ?!  Hmm - consensus means that everyone is for. I don't think 
>> we will have it. So we can stop now, no?  I think a simple majority is a 
>> meaningful way to vote here. 
>>
>
> Also, given the level of activity here, a separate thread for voting on 
> this (whenever that becomes appropriate, presumably one would want at least 
> a full week of discussion on the current one to allow for people on 
> vacation, etc. to catch up) probably will also attract a high level of 
> interest from anyone who cares, and be easily completable in a short time 
> period.
>

+1 on using a separate thread for the vote. 
Let me add that we should issue strict guidance that voters should not 
explain their reasons for their vote in the thread for the vote: Voters 
should read a carefully prepared proposal, a summary of a carefully 
prepared list of pros and cons, and optionally the full discussion thread.
Also +1 on the suggestion to use something like '2/3 majority of "Yes" and 
"Won't oppose" combined'.


-- 
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/06b74615-150e-42da-a16d-f92f28b4d32an%40googlegroups.com.

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

2022-09-13 Thread William Stein

On Tue, Sep 13, 2022 at 6:25 AM TB  wrote:
> Somewhere in this thread, or in a related thread, the trac backups were 
> mentioned. It reminded me of the the incident
> https://www.asmeurer.com/blog/posts/the-sympy-hackerrank-dmca-incident/
> where SymPy was wrongfully accused of a copyright violation, and got their 
> docs repo and docs website taken down by GitHub. The issue was resolved, and 
> for more details the above post by Aaron Meurer is a recommended reading. One 
> hint I got from this is that any plan to migrate to a new platform should 
> include a plan to migrate out of this platform.

Thanks for posting this fascinating blog post.  It's interesting that
their conclusion was:  "I do feel that being on a site like GitHub is
still preferable to something like self-hosting.  If you self-host,
you become responsible for a ton of things which GitHub does for you,
like making sure everything stays online, handling servers, and
managing spam. Also, self-hosting does not magically shield you from
legal threats. If you self-host content that infringes on someone’s
copyright, you are still legally liable for hosting that content."

It's also worrisome as you point out that they say "I have been
looking into effective
ways to backup this data [all GitHub issues and pull request history].
If anyone has any
suggestions here, please let me know in the comments."

A google search leads to this page that has three solutions:

https://rewind.com/blog/three-ways-to-backup-your-github-issues/

One of the thre options is BackupHub from Atlassian --
https://rewind.com/products/backups/github/
It looks trivial to use, but it's not free, and it's very unclear how
much it would cost for sagemath.
The other options involve the GitHub API, which I've used and is
actually really good.

 -- William

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

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CACLE5GD1LV-Hx-BO2cmL74bjrZN%3D4MnQKjspWSHBPh5L0L03WQ%40mail.gmail.com.

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

2022-09-13 Thread TB

First, I would like to thank all past,
present and future maintainers of the SageMath infrastructure.
This is a hard job, which is not always acknowledged.

Somewhere in this thread, or in a
related thread, the trac backups were mentioned. It reminded me of
the the incident
https://www.asmeurer.com/blog/posts/the-sympy-hackerrank-dmca-incident/
where SymPy was wrongfully accused of a
copyright violation, and got their docs repo and docs website
taken down by GitHub. The issue was resolved, and for more details
the above post by Aaron Meurer is a recommended reading. One hint
I got from this is that any plan to migrate to a new platform
should include a plan to migrate out of this platform.

The third point from the lessons
learned there is "Make backups of your online data". The source
code for Sage and its GH wiki are git repos, so it should be
relatively easy to have some kind of a continuous append-only
backup off-GitHub. Making backups (in a continuous way ready for
migration) of GH issues and PRs seems to be a point that require
more work, cf.
https://stackoverflow.com/questions/67352788/how-to-backup-or-transfer-my-github-things-other-than-code-pr-issue-wiki
and https://docs.gitlab.com/ee/user/project/import/github.html

From old previous threads about GH/GL
migration, I recall that many indeed wanted to replace trac, but
preferred GL over GH. One of the advantages described then is the
possibility for self-hosting GL, and easier moving between
gitlab.com and self-hosting. In this thread it seems GH is
preferred, noting popularity of the platform and CI/CD process.
FWIW, I like trac, and even like its web interface over those of
GH and GL, but I am not one of the maintainers of the SageMath
infrastructure...

Regards,
TB

On 11/09/2022 2:19, Nathan Dunfield
wrote:

I think moving to GitHub makes total sense. Every other
open-source math project I use regularly is on GH, and there are
big network-effect benefits to being where everyone else is as
others have already pointed out: easier for others to contribute,
easier to get credit for contributions, easier cross references to
issues up and downstream, etc. Given the range of projects that
use GH, including those like numpy and scipy whose issue/PR counts
are similar to the number Sage trac tickets, I'm sure any
technical or workflow issues have already been overcome by others
and the solutions are likely even documented. Given the
open-source community's reliance on GH, any serious misbehavior on
GH's part would result in a massive pushback and, if necessary, a
concerted effort by a huge number of people to work out an
alternative.

Nathan
--
You received this message because you are subscribed to the Google
Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/59ec7a86-18c7-4296-84d9-04c250ec27b6n%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/d5f7f9fe-4e7c-41c9-9844-6c85523bc3ff%40gmail.com.

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

2022-09-13 Thread kcrisman



> > Consensus ?!  Hmm - consensus means that everyone is for. I don't think 
> we will have it. So we can stop now, no?  I think a simple majority is a 
> meaningful way to vote here. 
>

Also, given the level of activity here, a separate thread for voting on 
this (whenever that becomes appropriate, presumably one would want at least 
a full week of discussion on the current one to allow for people on 
vacation, etc. to catch up) probably will also attract a high level of 
interest from anyone who cares, and be easily completable in a short time 
period.

-- 
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/c5ac66f7-fb0d-48a1-a708-5780e09ce9ebn%40googlegroups.com.

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

2022-09-13 Thread kcrisman



> While I strongly support the shift to github, I also agree with Travis 
> that we should vote on a change this major, and give the community enough 
> time to weigh in.  I would also encourage people on both sides of the 
> debate to give everyone the benefit of the doubt.  To those who have been 
> putting in a ton of work attempting to fix trac in recent weeks, our broken 
> infrastructure is both frustrating and gives a sense of urgency.  To those 
> who have spent over a decade using trac, the most recent iteration of this 
> discussion (starting four days ago) feels very rushed.
>

Well said on both counts.

> Consensus ?!  Hmm - consensus means that everyone is for. I don't think 
we will have it. So we can stop now, no?  I think a simple majority is a 
meaningful way to vote here. 
 
I think that's been the historical practice (recall the document William 
refers to in the Bernoulli # thread, which I think said something like at 
least 5 or 10 total votes + majority, though I also no longer know where it 
resides), but it probably wouldn't hurt to ask for a 2/3 majority to work 
against buyer's regret (see Saari's Basic Geometry of Voting for a nice 
historical example of this still in use) since that is as close to a "true" 
consensus we are likely to achieve here.  Or at least a 2/3 majority of 
"Yes" and "Won't oppose" combined, since I find myself in the latter camp - 
and I think with continued careful discussion of the technical challenges 
of keeping Trac alive combined with continued concrete proposals for how to 
most safely transition to GH (GL?) that won't be a problem to get.

-- 
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/51062568-886c-495e-9672-cce4d702de80n%40googlegroups.com.

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

On Tue, Sep 13, 2022 at 10:43 AM Eric Gourgoulhon
 wrote:
>
> Le mardi 13 septembre 2022 à 07:30:23 UTC+2, David Roe a écrit :
>>
>>
>> Here's a proposal on a timeline for making a decision (I welcome feedback 
>> from anyone who thinks this is too fast or too slow).
>>
>> * We spend another few days discussing pros and cons and refining the 
>> proposed workflows.
>> * I'll volunteer to collate the arguments that have been made into a list of 
>> pros and cons together with a concrete proposal, and we can send out an 
>> email in a separate thread announcing a vote later this week.
>> * The deadline for voting will be one week from the announcement (so, late 
>> next week).
>> * If the consensus of the community is to switch to github, then a smaller 
>> group can proceed with implementation (I'm also willing to be involved in 
>> that effort).

Consensus ?!
Hmm - consensus means that everyone is for. I don't think we will have it.
So we can stop now, no?

I think a simple majority is a meaningful way to vote here.

Dima



>
>
> +1 for this proposal.
>
> Eric.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/02148649-81f9-4838-b28f-a086e27b9667n%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/CAAWYfq28%2BWaqNh2QL2UoY0fjXm57BV5efFz2-r7x8YPzf1Ar4w%40mail.gmail.com.

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

2022-09-13 Thread Eric Gourgoulhon

Le mardi 13 septembre 2022 à 07:30:23 UTC+2, David Roe a écrit :

>
> Here's a proposal on a timeline for making a decision (I welcome feedback 
> from anyone who thinks this is too fast or too slow).
>
> * We spend another few days discussing pros and cons and refining the 
> proposed workflows.
> * I'll volunteer to collate the arguments that have been made into a list 
> of pros and cons together with a concrete proposal, and we can send out an 
> email in a separate thread announcing a vote later this week.  
> * The deadline for voting will be one week from the announcement (so, late 
> next week).
> * If the consensus of the community is to switch to github, then a smaller 
> group can proceed with implementation (I'm also willing to be involved in 
> that effort).
>

+1 for this proposal. 

Eric.  

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/02148649-81f9-4838-b28f-a086e27b9667n%40googlegroups.com.

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

2022-09-13 Thread Tobias Diez

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 user proposing a new feature or reporting a bug. This is 
reflected in that the discussion in an issue is largely on a meta-level. 
For example, discussing weather the proposed feature is actually needed or 
fit into the roadmap of the project; or for bugs outline how it can be 
reproduced. Discussions in pull requests on the other hand revolve more 
around the proposed implementation, code style and other such feedback.

Misstyping an issue reference is not very common on github since it 
provides a nice auto-completion / hover functionality that displays the 
full name of the referenced issue or pull request.

On Tuesday, 13 September 2022 at 07:25:57 UTC+2 Travis Scrimshaw wrote:

>
>> The downside (that will always remain to me) with GH/GL is anything with 
>>> their web interface is highly decentralized, 
>>>
>>
>> No, no such thing.
>>
>
> The fact that PRs and issues are on two completely different pages is 
> already decentralized. There is no clear single place for discussion, with 
> multiple PRs that can have their own threads.
>
>>  
>>
>>> whereas with trac, things are highly concentrated on tickets, which are 
>>> a single point of reference. Using the GH/GL model, we have all of these 
>>> forks
>>>
>>
>> Irrelevant because in the proposed workflow you never look at another 
>> developer's fork.
>>
>
> This is not true. You do not have a central point for branch access. Now 
> because of PRs that get attached to the main project, they do become 
> centralized. However, I cannot easily share or get a branch from another 
> developer that is not linked by a PR.
>
>>
>> (which we have to tell newbies are not the same as branches and should 
>>> not be used as such).
>>>
>> There is also more manual things we have to type and sync subject to 
>>> human (typo) error. This is likely manageable to me compared to some of the 
>>> other benefits (although I will personally experience none of those). 
>>> Despite this, I still have reservations about the increased pains of 
>>> development from trying to fit a mostly square peg into a round hole, and 
>>> subsequently am still opposed to the move
>>>
>>
>> Sorry, this is just a rant based on nothing
>>
>
> Matthias, your dismissive attitude is not helpful. I am even starting to 
> come around that this move could have benefits that outweigh the costs.
>
> The linking of issues to PRs is something that a human has to manually 
> type in, right? (Just today I mistyped a ticket number on trac.) For trac 
> tickets, you would have had to not realized you were on the wrong page, 
> which is far less subtle. My opposition also based on how easy it is to 
> share and manage different branches and communication of things involving a 
> single issue.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a932a629-9b04-4eb2-be22-5c55ac9c886dn%40googlegroups.com.

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

2022-09-13 Thread Tobias Diez

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". 
Especially since Travis made it clear that its not a hard requirement for 
him to send branches around by email but that he is wondering weather this 
would still be helpful.

On Tuesday, 13 September 2022 at 10:17:58 UTC+2 Matthias Koeppe wrote:

> All, let's please not expand the discussion of exotic workflows. 
>
> Sharing files, sharing branches etc. is a solved problem, with multiple 
> easy solutions. This is not 2005 any more, when having an SVN server was 
> the gold standard to sharing & versioning files.
>
>
> On Tuesday, September 13, 2022 at 1:03:59 AM UTC-7 Matthias Koeppe wrote:
>
>> On Tuesday, September 13, 2022 at 12:57:47 AM UTC-7 Travis Scrimshaw 
>> wrote:
>>
>>> With our current setup, I could push the branch to the server, email you 
>>> the branch name, and you could pull it.
>>>
>>
>> So you're discussing a use case of the trac git server to share a branch 
>> that has nothing to do with a trac ticket.
>> Doesn't sound like anything that needs a solution.
>>
>>  
>>
>

-- 
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/eb743bc1-9e89-4f0f-9cb5-0b7fc6d1bfa7n%40googlegroups.com.

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

All, let's please not expand the discussion of exotic workflows. 

Sharing files, sharing branches etc. is a solved problem, with multiple 
easy solutions. This is not 2005 any more, when having an SVN server was 
the gold standard to sharing & versioning files.

On Tuesday, September 13, 2022 at 1:03:59 AM UTC-7 Matthias Koeppe wrote:

> On Tuesday, September 13, 2022 at 12:57:47 AM UTC-7 Travis Scrimshaw wrote:
>
>> With our current setup, I could push the branch to the server, email you 
>> the branch name, and you could pull it.
>>
>
> So you're discussing a use case of the trac git server to share a branch 
> that has nothing to do with a trac ticket.
> Doesn't sound like anything that needs a solution.
>
>  
>

-- 
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/b10abc34-2be8-4a2e-924a-e0c9b2942ddan%40googlegroups.com.

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

On Tue, 13 Sep 2022, 08:57 'Travis Scrimshaw' via sage-devel, <
sage-devel@googlegroups.com> wrote:

>
> On Tuesday, September 13, 2022 at 4:14:26 PM UTC+9 Matthias Koeppe wrote:
>
>> On Tuesday, September 13, 2022 at 12:10:28 AM UTC-7 Travis Scrimshaw
>> wrote:
>>
>>> How is the workflow that our current developers sometimes use
 irrelevant? Granted, this is a less used feature, but I believe it makes it
 harder to share branches privately. It has been useful for me in the past
 to have this (e.g., some hacked together code meant only to be shared with
 collaborators).

>>>
>> I think you'll have to explain what workflow is what you are talking
>> about, and what your concern is.
>>
>
> Let's say I want to solve the really hard problem of 2 + 2 for a paper we
> are writing. So I write a branch that does the computation by repeatedly
> adding 1: doing the computation 2 + 1 + 1. We don't plan to include this
> into Sage as it is a horrible hack nor make it public because it will lead
> to a proof of the Riemann Hypothesis (don't want to be scooped). Now you
> also want to run computations or build some code off of it. How do you get
> the code? We do not want to do a PR. With our current setup, I could push
> the branch to the server, email you the branch name, and you could pull it.
> Using GH, my understanding is we would have to share a repo and/or setup
> push/pull rights, which seems more complicated
>

no, with GH you can just the same way email someone a branch name on your
fork of the main repo, where is the problem here?

(and what if I want to get stuff back from you too?).
>

same, you can pull a branch from someone's fork.

PS. With git, one actually don't need any repos on servers, one can email
branches around, this is the workflow of the Linux kernel project. It's not
just patch-quilts, it is a mature system which used and checks hashes of
commits in your branches.
Cf. e.g.
https://git-send-email.io/


> Does that clarify things? Admittedly I don't use it that often (and I am
> willing to deal with such issues as they might arise later), but I don't
> know about other practitioners at-large.
>
> --
> 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/05414f99-c449-4951-9f76-1d73175932c8n%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/CAAWYfq38niCkZ2j9ThDs%3D%3D2jozEgg74sqO7gnVN5keye%2BEmm6A%40mail.gmail.com.

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

2022-09-13 Thread David Roe

On Tue, Sep 13, 2022 at 3:57 AM 'Travis Scrimshaw' via sage-devel <
sage-devel@googlegroups.com> wrote:

>
> On Tuesday, September 13, 2022 at 4:14:26 PM UTC+9 Matthias Koeppe wrote:
>
>> On Tuesday, September 13, 2022 at 12:10:28 AM UTC-7 Travis Scrimshaw
>> wrote:
>>
>>> How is the workflow that our current developers sometimes use
 irrelevant? Granted, this is a less used feature, but I believe it makes it
 harder to share branches privately. It has been useful for me in the past
 to have this (e.g., some hacked together code meant only to be shared with
 collaborators).

>>>
>> I think you'll have to explain what workflow is what you are talking
>> about, and what your concern is.
>>
>
> Let's say I want to solve the really hard problem of 2 + 2 for a paper we
> are writing. So I write a branch that does the computation by repeatedly
> adding 1: doing the computation 2 + 1 + 1. We don't plan to include this
> into Sage as it is a horrible hack nor make it public because it will lead
> to a proof of the Riemann Hypothesis (don't want to be scooped). Now you
> also want to run computations or build some code off of it. How do you get
> the code? We do not want to do a PR. With our current setup, I could push
> the branch to the server, email you the branch name, and you could pull it.
> Using GH, my understanding is we would have to share a repo and/or setup
> push/pull rights, which seems more complicated (and what if I want to get
> stuff back from you too?).
>
> Does that clarify things? Admittedly I don't use it that often (and I am
> willing to deal with such issues as they might arise later), but I don't
> know about other practitioners at-large.
>

You can create branches on your own fork, and create pull requests to
others' forks.  If you're working on a feature that's not yet ready to be
shared more broadly, the Sagemath github repository wouldn't need to be
involved at all.
David

> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/05414f99-c449-4951-9f76-1d73175932c8n%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/CAChs6_nfChm8vV_Jbm1LNFcy0nhhd98OjvsbG7pUm%3D8ebPhWOw%40mail.gmail.com.

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

On Tuesday, September 13, 2022 at 12:57:47 AM UTC-7 Travis Scrimshaw wrote:

> With our current setup, I could push the branch to the server, email you 
> the branch name, and you could pull it.
>

So you're discussing a use case of the trac git server to share a branch 
that has nothing to do with a trac ticket.
Doesn't sound like anything that needs a solution.

-- 
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/205fe134-e838-4603-8da5-1abd7b36cbfen%40googlegroups.com.

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

2022-09-13 Thread 'Travis Scrimshaw' via sage-devel

On Tuesday, September 13, 2022 at 4:14:26 PM UTC+9 Matthias Koeppe wrote:

> On Tuesday, September 13, 2022 at 12:10:28 AM UTC-7 Travis Scrimshaw wrote:
>
>> How is the workflow that our current developers sometimes use irrelevant? 
>>> Granted, this is a less used feature, but I believe it makes it harder to 
>>> share branches privately. It has been useful for me in the past to have 
>>> this (e.g., some hacked together code meant only to be shared with 
>>> collaborators).
>>>
>>
> I think you'll have to explain what workflow is what you are talking 
> about, and what your concern is.
>

Let's say I want to solve the really hard problem of 2 + 2 for a paper we 
are writing. So I write a branch that does the computation by repeatedly 
adding 1: doing the computation 2 + 1 + 1. We don't plan to include this 
into Sage as it is a horrible hack nor make it public because it will lead 
to a proof of the Riemann Hypothesis (don't want to be scooped). Now you 
also want to run computations or build some code off of it. How do you get 
the code? We do not want to do a PR. With our current setup, I could push 
the branch to the server, email you the branch name, and you could pull it. 
Using GH, my understanding is we would have to share a repo and/or setup 
push/pull rights, which seems more complicated (and what if I want to get 
stuff back from you too?).

Does that clarify things? Admittedly I don't use it that often (and I am 
willing to deal with such issues as they might arise later), but I don't 
know about other practitioners at-large.

-- 
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/05414f99-c449-4951-9f76-1d73175932c8n%40googlegroups.com.

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

On Tuesday, September 13, 2022 at 12:02:19 AM UTC-7 Travis Scrimshaw wrote:

> From a number of trac tickets (mainly #30363) and the GitHub UN link 
> thread coming across more as a demand to me with the imposed deadline, it 
> gave off this impression.
>

Can't criticize both lack of a plan & activity to prepare a plan...
 

> Sorry for the overstatement. 
>

Don't worry about 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/9bff778a-5568-400d-a5b4-97202c28d5can%40googlegroups.com.

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

On Tue, 13 Sep 2022, 04:39 'Travis Scrimshaw' via sage-devel, <
sage-devel@googlegroups.com> wrote:

> First off, we need to slow down significantly as we do not have an general
> clear consensus about doing this move. A few people are yelling we should
> move to GH, and a lot of the same people are acting like has been decided
> when it has not. We should make a formal vote once a more concrete proposal
> has been placed forward.
>
Even setting aside the immediate operational problems with trac, which are
lingering on for about 3 weeks now, with no end in sight, we still have to
move.

I don't think we need a formal vote.
Holding it is akin to voting on whether to stay 32-bit, or move to 64-bit...

Yes, we have some people saying they prefer to stay on trac, but we don't
have resources to stay on trac. And trac, as a project, is going away by
itself. It is a bug, essentially, that we are still on trac.
Do we need a vote to fix a bug, or not? I think we don't.

Dima


> On Tuesday, September 13, 2022 at 4:36:04 AM UTC+9 Matthias Koeppe wrote:
>
>> On Saturday, September 10, 2022 at 7:39:10 AM UTC-7 Travis Scrimshaw
>> wrote:
>>
>>> [] There are lots of technical issues and questions I have that
 [I cannot] easily find after skimming through things for a few minutes.

>>>
>> Everything about GitHub has excellent documentation, and we have an
>> executive summary now at
>> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b,
>> with pointers to the relevant bits.
>>
>
> This is still does not contain much of any details about the collaboration
> process. It is basically contains the simple single-author--single-reviewer
> model (that is easy to find) and a thesaurus of terms.
>
> What happens when Bob works on a ticket, but then stops (say, it doesn't
> find a reviewer in time). Now Alice wants to make changes on top of that
> branch. How does Alice do that? I am particularly thinking about when this
> is *not* meant to be a PR review commit (say, it is working with a more
> substantial change or just cherry-picking some of the commits). When she is
> done, does she do a new PR? After doing quite a bit of digging, I finally
> found the answer:
>
>
> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally
>
> So there is a mechanism for it, but it is not as straightforward as
> before. How do we deal with the PR pollution?
>
>
>>
>>> It stays there even if the user GitHub account is closed (the latter
 triggers an automatic closure of the PR, but the underlying
 branch remains in the repo, it can be worked on just the same using git)

>>>
>>> Which repo? Either way, this seems like a regression compared to our
>>> current setup, where if a user quits, then branch, ticket, and everything
>>> remains.
>>>
>>
>> No, this is an imaginary problem. The branch of the pull request persists
>> in the sagemath repo (see
>> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b,
>> which explains the name of the branch) even if the user and their repo
>> disappears.
>>
>
> Okay, thanks. The extra information clarifies things.
>
>>
>> Getting the login credentials was the biggest barrier; everything else is
> mostly straightforward and based on very simple git commands.
>

> Right now, I find there are way too many practical questions and
> barriers for how we develop that make moving to Git**b a much bigger pain
> that people will think it is.
>

 Travis, many people nowadays never used git without GitHub or GitLab.
 For such a person it's a major pain to
 learn our workflow.

>>>
>>> Do you really believe that everyone is using the web interface to make
>>> edits to the code and not using some form of git locally (either command
>>> line or GUI based)?
>>>
>> The web interface has major problems, such as not being able to run tests
>>> locally, in addition to being unwieldy with a project on the scale of Sage.
>>> Honestly, people really don't use "git pull", "git push", "git commit" when
>>> working with *Git*hub?
>>>
>>
>> Nothing like this is being proposed. No, GitHub is not a replacement for
>> git. Yes, you will continue to use git commands to pull, push, commit.
>>
>> But people nowadays who start with GitHub never have to go through
>> archaic setup steps such as those that we document at
>> https://doc.sagemath.org/html/en/developer/trac.html#trac-authentication-through-ssh,
>> which --- even when it is working --- is major friction for the project.
>>
>
> I think it has been just far too long since you uploaded your ssh key to
> GH. The server cannot magically know your ssh public key. Yes, we don't
> have https support, but other than the most casual of contributors will use
> that for push/pull. I highly doubt anyone will use that feature with any
> serious commits.
>
> It seems like there are just as many one-time

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

On Tuesday, September 13, 2022 at 12:10:28 AM UTC-7 Travis Scrimshaw wrote:

> How is the workflow that our current developers sometimes use irrelevant? 
>> Granted, this is a less used feature, but I believe it makes it harder to 
>> share branches privately. It has been useful for me in the past to have 
>> this (e.g., some hacked together code meant only to be shared with 
>> collaborators).
>>
>
I think you'll have to explain what workflow is what you are talking about, 
and what your concern is.

 

-- 
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/f2d57d68-1f43-4cc6-bba6-f9f729acd980n%40googlegroups.com.

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

2022-09-13 Thread 'Travis Scrimshaw' via sage-devel


On Tuesday, September 13, 2022 at 3:30:19 PM UTC+9 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 10:25:57 PM UTC-7 Travis Scrimshaw wrote:
>
>> whereas with trac, things are highly concentrated on tickets, which are a 
 single point of reference. Using the GH/GL model, we have all of these 
 forks

>>>
>>> Irrelevant because in the proposed workflow you never look at another 
>>> developer's fork.
>>>
>>
>> This is not true. You do not have a central point for branch access. Now 
>> because of PRs that get attached to the main project, they do become 
>> centralized.
>>
>
> Yes, in the proposed workflow everything goes through PRs. 
>
> Yes, GitHub, like git, can also be used for other development workflows, 
> but such other workflows are not part of the proposal. Hence irrelevant.
>
> How is the workflow that our current developers sometimes use irrelevant? 
Granted, this is a less used feature, but I believe it makes it harder to 
share branches privately. It has been useful for me in the past to have 
this (e.g., some hacked together code meant only to be shared with 
collaborators).
 

-- 
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/3fb68342-7efb-42d6-8163-89905bb557e3n%40googlegroups.com.

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

2022-09-13 Thread 'Travis Scrimshaw' via sage-devel

On Tuesday, September 13, 2022 at 3:36:18 PM UTC+9 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 10:36:06 PM UTC-7 Travis Scrimshaw wrote:
>
>> Last I remember, using https instead of ssh meant I had to input my UN/PW 
>> every time I did a push or a pull
>>
>
>
> https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git
>  
>
I was not aware of that. I don't remember that being there when I first 
started using git and GH (some 10+ years ago I think). Perhaps I should 
have checked this more thoroughly. Nevertheless, good to know.

-- 
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/6f3dc6ec-036d-4941-a684-8e726753b0dfn%40googlegroups.com.

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

2022-09-13 Thread 'Travis Scrimshaw' via sage-devel


On Tuesday, September 13, 2022 at 3:42:58 PM UTC+9 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 10:30:39 PM UTC-7 Travis Scrimshaw wrote:
>
>> Please, Travis, the high activity that you see here is in response to the 
>>> requests for having a fleshed out plan before a discussion can even happen. 
>>> So we fleshed out the plan. 
>>> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
>>>
>>> Maybe I am reading too much into some of the other things that have been 
>> happening, but I got the impression that things are being written as "this 
>> is happening".
>>
>
> Yes, you are mistaken. The description of the proposed workflow has 
> "*Proposed* Workflow" in the heading.
>
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-workflow-on-github-with-transition-guide-from-trac
> It is the draft of the transition guide to the proposed workflow.
> Of course, the transition guide itself is written from the perspective of 
> how to work with the workflow -- and working with the workflow only makes 
> sense after it has been adopted.
>

>From a number of trac tickets (mainly #30363) and the GitHub UN link thread 
coming across more as a demand to me with the imposed deadline, it gave off 
this impression. Sorry for the overstatement. 

-- 
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/664781bf-19a2-41d4-9c2d-600062d16176n%40googlegroups.com.

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

On Monday, September 12, 2022 at 10:30:23 PM UTC-7 David Roe wrote:

> Here's a proposal on a timeline for making a decision (I welcome feedback 
> from anyone who thinks this is too fast or too slow).
>
> * We spend another few days discussing pros and cons and refining the 
> proposed workflows.
> * I'll volunteer to collate the arguments that have been made into a list 
> of pros and cons together with a concrete proposal, and we can send out an 
> email in a separate thread announcing a vote later this week.  
> * The deadline for voting will be one week from the announcement (so, late 
> next week).
> * If the consensus of the community is to switch to github, then a smaller 
> group can proceed with implementation (I'm also willing to be involved in 
> that effort).
>

Sounds good to me. I don't think anyone had a faster timeline for this in 
mind.
For reference - for the call to provide GitHub account names 
(https://groups.google.com/g/sage-devel/c/QooOF1GLMOs) -- which is a 
prerequisite for a Trac-to-GH-Issues conversion, I set a target of Sep 26 
(2 weeks) from now.

(And note that my call has multiple uses -- the GitHub account names are 
useful for cross-referencing either way; the call also asks to update other 
details for our website; and we get rid of the full name list on the Trac 
front page, which is outdated after the Trac 1.2 update.)

-- 
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/248120e1-68c2-47fa-8033-a6e1dd3d328bn%40googlegroups.com.

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

On Monday, September 12, 2022 at 10:30:39 PM UTC-7 Travis Scrimshaw wrote:

> Please, Travis, the high activity that you see here is in response to the 
>> requests for having a fleshed out plan before a discussion can even happen. 
>> So we fleshed out the plan. 
>> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
>>
>> Maybe I am reading too much into some of the other things that have been 
> happening, but I got the impression that things are being written as "this 
> is happening".
>

Yes, you are mistaken. The description of the proposed workflow has 
"*Proposed* Workflow" in the heading.
https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-workflow-on-github-with-transition-guide-from-trac
It is the draft of the transition guide to the proposed workflow.
Of course, the transition guide itself is written from the perspective of 
how to work with the workflow -- and working with the workflow only makes 
sense after it has been adopted.

-- 
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/0a5603ce-a3d5-4e23-9ba4-b49a51049e2an%40googlegroups.com.

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