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

[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

[Dima Pasechnik]

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

[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

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

[sage-devel] Re: Should really `make configure` download files on error?

[Matthias Koeppe]

On Friday, September 16, 2022 at 8:43:22 AM UTC-7 mpn7...@gmail.com wrote:

> What happened is that the `bootstrap` script, in charge of building the 
> `configure` script, had failed to build and decided to download a 
> configure script from sage's mirrors as a fallback (as told by the -d 
> flag). 
> Because this only prints an error message but does not fail, `make 
> build` kept running and completed successfully. I didn't see the error 
> message in the pile of logs that it produces. 
>
> While I understand that downloading a fallback configure script can be 
> okay in many cases, I don't think this is a good default behaviour. 
> I would rather have `make build` fail, tell me about `./bootstrap -d`, 
> and let me decide if I want to address the problem or use the fallback 
> script. 
>
> Do you have any opinion on this?
>

It's a mechanism that is suitable/convenient for the majority of all 
tickets and users.

Only developers who work with tickets that add packages or make changes to 
the build infrastructure run into the problem that the downloaded 
"configure" is not suitable.

 

-- 
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/cd16a988-b0b4-4a64-a73c-b79f5d99ff02n%40googlegroups.com.

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

[Dima Pasechnik]

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

[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] Should really `make configure` download files on error?

[Dima Pasechnik]

IMHO ./bootsrtap should not be invoked by any of our 'make' targets.

same for ./configure (I can't recall any real reason, apart from
convenience, that we do this)





On Fri, 16 Sep 2022, 16:43 Martin Pépin,  wrote:

> Hi all,
>
> I had a weird issue with sage recently which boiled down to `make build`
> completing without an error (at first glance) but giving me an
> ill-configured sage.
>
> What happened is that the `bootstrap` script, in charge of building the
> `configure` script, had failed to build and decided to download a
> configure script from sage's mirrors as a fallback (as told by the -d
> flag).
> Because this only prints an error message but does not fail, `make
> build` kept running and completed successfully. I didn't see the error
> message in the pile of logs that it produces.
>
> While I understand that downloading a fallback configure script can be
> okay in many cases, I don't think this is a good default behaviour.
> I would rather have `make build` fail, tell me about `./bootstrap -d`,
> and let me decide if I want to address the problem or use the fallback
> script.
>
> Do you have any opinion on this? I'm happy to open a ticket implementing
> my suggestion.
> (And sorry if that's been discussed already.)
>
> Cheers,
> Martin
>
> --
> 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/81df7ef1-d924-9e31-3348-8988fbea89e8%40gmail.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/CAAWYfq15wHApRnaZ67q_KSOHBnD%3DTm0d2_J%2BEkGq01o8Vtqnnw%40mail.gmail.com.

[sage-devel] Should really `make configure` download files on error?

[Martin Pépin]

Hi all,

I had a weird issue with sage recently which boiled down to `make build` 
completing without an error (at first glance) but giving me an 
ill-configured sage.


What happened is that the `bootstrap` script, in charge of building the 
`configure` script, had failed to build and decided to download a 
configure script from sage's mirrors as a fallback (as told by the -d flag).
Because this only prints an error message but does not fail, `make 
build` kept running and completed successfully. I didn't see the error 
message in the pile of logs that it produces.


While I understand that downloading a fallback configure script can be 
okay in many cases, I don't think this is a good default behaviour.
I would rather have `make build` fail, tell me about `./bootstrap -d`, 
and let me decide if I want to address the problem or use the fallback 
script.


Do you have any opinion on this? I'm happy to open a ticket implementing 
my suggestion.

(And sorry if that's been discussed already.)

Cheers,
Martin

--
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/81df7ef1-d924-9e31-3348-8988fbea89e8%40gmail.com.

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

[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

[Dima Pasechnik]

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

[Dima Pasechnik]

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

[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

[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

[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

[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

[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

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