On Fri, Sep 9, 2022 at 4:06 PM John Cremona <john.crem...@gmail.com> wrote: > > To me, as a contributor of code to Sage who has not contributed at all > to the backend support, it seems that there is a clear majority in > favour of moving to github. As an ordinary developer I would be very > happy with that. > > It looks to me as if Frédéric's main issue with github is his final > point "...We should rather not bow under the power of large > private companies.".
my reply to Frederic got posted ahead of his post, as he didn't cc to sage-devel. I wrote there that I don't see how to consolidate the latter wish with us currently paying a huge private corporation, and a rather evil one, a figure of about US$4000 p.a . for hosting. > I don't know enough about gitlab to know if it > is a sensible alternative, but I myself have no problem with using > github for this, as I do for just about everything else. > > John > > On Fri, 9 Sept 2022 at 15:10, Thierry <sage-googlesu...@lma.metelu.net> wrote: > > > > Hi, > > > > let me forward the email of Frédéric as a whole, so that the thread remains > > complete. > > > > ----- Forwarded message from Frédéric Chapoton <fchapot...@gmail.com> ----- > > > > Date: Fri, 9 Sep 2022 12:15:25 +0200 > > From: Frédéric Chapoton > > To: sagemath-adm...@googlegroups.com > > Subject: Re: [sagemath-admins] Fwd: [sage-devel] Re: incremental migration > > to github? [prompted by FUNDING issues!!!] + general flakiness of trac > > > > Dear sage developers and maintainers, > > > > Whereas I agree that we currently have two issues, I do not agree on the > > necessity to switch to github and certainly not urgently. > > > > * The first issue is the cost of google compute engine. This is under > > investigation and can be lowered by creating a new project. This should be > > do-able and could save us 3 $ per day. > > * The second issue is about new users entering new ssh keys. There is hope > > to fix that and in the mean-time one could ask new users to send sshkeys to > > some of us. > > > > My own preference would be to go on using trac, for some years, as this is > > serving us quite well. We should not change this for superficial and > > temporary reasons. > > > > The serious reasons that I see are : money and the futre of the trac > > software itself. > > > > In my opinion, money is the only serious issue, and I would like to see > > trac heberged by some university. There are already several services in > > France, so another country would be better. Germany ? Somebody must step > > forward. > > > > About the trac software, it now has a python3-compatible version, available > > on most linux distributions. We should aim to use that. Once done, the > > situation will be stable. > > > > As a side matter, it seems to me that gitlab is much more in the spirit of > > open source software. We should rather not bow under the power of large > > private companies. > > > > Frédéric > > > > ----- > > > > > > > > On Fri, Sep 09, 2022 at 12:15:13PM +0100, Dima Pasechnik wrote: > > > On Fri, Sep 9, 2022 at 11:15 AM Frédéric Chapoton <fchapot...@gmail.com> > > > wrote: > > > > > > > > Dear sage developers and maintainers, > > > > > > > > Whereas I agree that we currently have two issues, I do not agree on > > > > the necessity to switch to github and certainly not urgently. > > > > > > it is a disaster that new people can't come aboard easily. It really is > > > urgent. > > > A convoluted system to get new developers onboard and contributing is > > > a very bad omen for open-source projects, it really is. > > > > > > E.g. try to contribute to something like OpenBSD - I'd sure most > > > potentail contributors run away screaming, > > > upon learning that they must use CVS and e-mail patches around for > > > approval. > > > > > > > > > > > * The first issue is the cost of google compute engine. This is under > > > > investigation and can be lowered by creating a new project. This should > > > > be do-able and could save us 3 $ per day. > > > > > > but this is far from free, still, and hosting prices are to go with > > > the energy prices, up and up. > > > It's really spending money on a questionable luxury, instead of > > > something useful. > > > > > > > * The second issue is about new users entering new ssh keys. There is > > > > hope to fix that and in the mean-time one could ask new users to send > > > > sshkeys to some of us. > > > > > > > > My own preference would be to go on using trac, for some years, as this > > > > is serving us quite well. We should not change this for superficial and > > > > temporary reasons. > > > > > > the reasons are not supreficial, in particular, trac+gitolite software > > > is obsolete. > > > I cannot imagine a new project that would choose it as a platform. > > > > > > > > > > > The serious reasons that I see are : money and the futre of the trac > > > > software itself. > > > > > > > > In my opinion, money is the only serious issue, and I would like to see > > > > trac heberged by some university. There are already several services in > > > > France, so another country would be better. Germany ? Somebody must > > > > step forward. > > > > > > > > About the trac software, it now has a python3-compatible version, > > > > available on most linux distributions. We should aim to use that. Once > > > > done, the situation will be stable. > > > > > > Why do you think so? The bus factors of trac and gitolite software are > > > very, very small. > > > (https://en.wikipedia.org/wiki/Bus_factor) > > > As well as the bus factor for our trac instance. > > > > > > > > > > > As a side matter, it seems to me that gitlab is much more in the spirit > > > > of open source software. We should rather not bow under the power of > > > > large private companies. > > > Let's not get into this argument. I don't see how paying Google's > > > adware criminals US$4000 per year is more ethical than moving over to > > > GitHub (which, by the way, gives us a bit of money, > > > via GitHub sponsors system :-)). > > > Besides, moving from GitHub to GitLab is rather easy, compared to move > > > from trac to Git**b. > > > > > > Dima > > > > > > > > > > > > > > > > > > > > Frédéric > > > > > > > > > > > > Le ven. 9 sept. 2022 à 11:55, Dima Pasechnik <dimp...@gmail.com> a > > > > écrit : > > > >> > > > >> ---------- Forwarded message --------- > > > >> From: Dima Pasechnik <dimp...@gmail.com> > > > >> Date: Fri, Sep 9, 2022 at 10:54 AM > > > >> Subject: Re: [sage-devel] Re: incremental migration to github? > > > >> [prompted by FUNDING issues!!!] + general flakiness of trac > > > >> To: sage-devel <sage-devel@googlegroups.com> > > > >> > > > >> > > > >> 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. > > > >> > > > >> > > > >> > > > >> *) normal - i.e. using trac interface; we (probably) still have a way > > > >> to modify the repository of ssh keys used by trac manually. > > > >> > > > >> On Thursday, March 18, 2021 at 10:53:54 AM UTC Frédéric Chapoton wrote: > > > >> > > > > >> > Erik, did you stop the Orsay runners for gitlab ? It seems that the > > > >> > docker build there for 9.3.b9 is stuck by lack of runners. > > > >> > > > > >> > https://gitlab.com/sagemath/sage/-/pipelines > > > >> > > > > >> > Frédéric > > > >> > > > > >> > Le jeudi 11 mars 2021 à 13:25:52 UTC+1, erik....@gmail.com a écrit : > > > >> >> > > > >> >> On Thu, Mar 11, 2021 at 1:20 PM E. Madison Bray > > > >> >> <erik....@gmail.com> wrote: > > > >> >> > > > > >> >> > On Thu, Mar 11, 2021 at 12:52 PM Dima Pasechnik > > > >> >> > <dim...@gmail.com> wrote: > > > >> >> > > > > > >> >> > > On Thu, Mar 11, 2021 at 10:11 AM Dima Pasechnik > > > >> >> > > <dim...@gmail.com> wrote: > > > >> >> > > > > > > >> >> > > > On Wed, Mar 10, 2021 at 4:00 PM E. Madison Bray > > > >> >> > > > <erik....@gmail.com> wrote: > > > >> >> > > > > > > > >> >> > > > > On Tue, Jan 12, 2021 at 11:33 PM tobia...@gmx.de > > > >> >> > > > > <tobia...@gmx.de> wrote: > > > >> >> > > > > > > > > >> >> > > > > > > > > >> >> > > > > > For what's worth, + 1 for migrating to github. > > > >> >> > > > > > > > > >> >> > > > > > The interface is cleaner, it has many more features and > > > >> >> > > > > > integrations, and is more active which could attract more > > > >> >> > > > > > contributions. There are a few scripts/tools that allow > > > >> >> > > > > > to migrate from trac to github. But most of them are > > > >> >> > > > > > unmaintained for a few years already, so I'm not sure if > > > >> >> > > > > > they still work (which should be taken as a sign that one > > > >> >> > > > > > should migrate sooner than later). > > > >> >> > > > > > > > >> >> > > > > In 2019 Julian Rüth and I, with the help of some others, > > > >> >> > > > > already put > > > >> >> > > > > in some effort to set up an organization for SageMath on > > > >> >> > > > > GitLab: > > > >> >> > > > > https://gitlab.com/sagemath > > > >> >> > > > > > > > >> >> > > > > Between GitHub and GitLab, we felt that the latter would be > > > >> >> > > > > more > > > >> >> > > > > acceptable to the broader Sage community. We also > > > >> >> > > > > implemented a bot > > > >> >> > > > > that can mirror GitLab merge requests as Trac tickets, > > > >> >> > > > > though it's > > > >> >> > > > > been in need of troubleshooting for a while. > > > >> >> > > > > > > > >> >> > > > > This was also done before the advent of GitHub Actions, and > > > >> >> > > > > the > > > >> >> > > > > ability to provide custom CI runners for GitLab Pipelines > > > >> >> > > > > seemed > > > >> >> > > > > advantageous, since we could maintain our own fleet of > > > >> >> > > > > runners, be it > > > >> >> > > > > on Sage developers' personal machines (if they are generous > > > >> >> > > > > enough to > > > >> >> > > > > host them) or any conceivable constellation of cloud > > > >> >> > > > > computing > > > >> >> > > > > platforms. > > > >> >> > > > > > > > >> >> > > > > In practice this has gained little traction, in part due to > > > >> >> > > > > lack of > > > >> >> > > > > advertising. The GitLab Runner solution also proved a bit > > > >> >> > > > > troublesome > > > >> >> > > > > to maintain, as it required some constant attention to make > > > >> >> > > > > sure there > > > >> >> > > > > were always working runners available. I tried to keep that > > > >> >> > > > > up for a > > > >> >> > > > > while myself, but have had other obligations. > > > >> >> > > > > > > >> >> > > > I think it should be mentioned that GitLab has an analog of > > > >> >> > > > GitHub Actions, > > > >> >> > > > and the difference is that its runners may be self-hosted, or > > > >> >> > > > provided > > > >> >> > > > by GitLab. > > > >> >> > > > E.g. see > > > >> >> > > > https://gitlab.com/sagemath/dev/trac/-/pipelines/266731297 > > > >> >> > > > > > >> >> > > I just tried to switch to a "community" runner, and got an > > > >> >> > > error which > > > >> >> > > is probably > > > >> >> > > obvious to people versed in Docker: > > > >> >> > > > > > >> >> > > https://gitlab.com/sagemath/dev/trac/-/jobs/1089520433 > > > >> >> > > > > >> >> > I think it might be because the Docker builds have been otherwise > > > >> >> > not > > > >> >> > working for a while (due to lack of reliable runners). So a more > > > >> >> > recent "build-from-clean" job is needed. These jobs are run when > > > >> >> > develop/master are updated as well as on tags. Whereas > > > >> >> > "built-from-latest" is run on branches for tickets. It tries to > > > >> >> > build > > > >> >> > the branch on top of the "latest" Docker image e.g. for develop. > > > >> >> > But > > > >> >> > the last one that built successfully is too old, and so trying to > > > >> >> > make > > > >> >> > the diff between that ticket and the version of develop it's > > > >> >> > based on > > > >> >> > fails. Hence the message: > > > >> >> > > > > >> >> > "Could not find commit fbca269f627bf6a8bc6f0a611ed7e26260ebc994 in > > > >> >> > your local Git history. Please merge in the latest built develop > > > >> >> > branch to fix this: git fetch trac && git merge > > > >> >> > fbca269f627bf6a8bc6f0a611ed7e26260ebc994" > > > >> >> > > > > >> >> > But for the automated CI that's not a very useful message... > > > >> >> > > > > >> >> > I know Matthias has done some impressive things to get around > > > >> >> > GitHub > > > >> >> > Actions' time limit on jobs by breaking the build up into "stages" > > > >> >> > that can be split across multiple jobs. I see no reason that > > > >> >> > couldn't > > > >> >> > work with GitLab as well. > > > >> >> > > > > >> >> > But it would still be better to have our own fleet of > > > >> >> > runners--they > > > >> >> > would be faster, and we could test on more different custom > > > >> >> > hardware > > > >> >> > configurations. The problem is that this is at a minimum a > > > >> >> > part-time > > > >> >> > job... > > > >> >> > > > >> >> Well looks like I need to correct the record a bit. Perhaps I've > > > >> >> been > > > >> >> a bit too sanguine about the state of the GitLab builds. In fact, > > > >> >> the > > > >> >> latest develop commit, 9.3beta8, built quite successfully: > > > >> >> https://gitlab.com/sagemath/sage/-/pipelines/266734885 > > > >> >> > > > >> >> And it ran on one of the fleet of runners I've been maintaining here > > > >> >> at Paris-Saclay, which I haven't touched in months. So I guess it's > > > >> >> still working after all ^^; Ever since I set this up I had been > > > >> >> having a problem with runners randomly erroring out, and not being > > > >> >> deleted correctly when they do. I have tried many times to fix it to > > > >> >> no avail, and I kind of gave up for a while. I assumed eventually > > > >> >> this caused things to grind to a halt, but apparently not. > > > >> >> > > > >> >> Knowing that it's still working at least somewhat gives me > > > >> >> motivation > > > >> >> to try again to investigate the problem with the erroring runners > > > >> >> and > > > >> >> see if it can't be fixed. Maybe an upgrade of the gitlab-runner > > > >> >> controller is in order... > > > >> > > > >> -- > > > >> 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/142912ca-a226-47a7-8ea4-6afe5711376fn%40googlegroups.com. > > > >> > > > >> -- > > > >> > > > >> --- > > > >> You received this message because you are subscribed to the Google > > > >> Groups "sagemath-admins" group. > > > >> To unsubscribe from this group and stop receiving emails from it, send > > > >> an email to sagemath-admins+unsubscr...@googlegroups.com. > > > >> To view this discussion on the web visit > > > >> https://groups.google.com/d/msgid/sagemath-admins/CAAWYfq2mC7yHKP%2B%3DGzvdAo0BrYiv-CMJ3r2xbMfBA-_8Jr-k8Q%40mail.gmail.com. > > > > > > > > -- > > > > > > > > --- > > > > You received this message because you are subscribed to the Google > > > > Groups "sagemath-admins" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to sagemath-admins+unsubscr...@googlegroups.com. > > > > To view this discussion on the web visit > > > > https://groups.google.com/d/msgid/sagemath-admins/CAL7VZwDQoUVKLrHazy2-%2BzW6LfdJ-zSavzgeBqU4F%3Db59Ub9vQ%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/CAAWYfq15a%2BnkQBzvZ7FKb2uG%2B01AdP%2BE3nxnVqL%3DbbmgdBb-pg%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/20220909141000.GA18932%40metelu.net. > > -- > 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/CAD0p0K78WEmRAfC7bPddU2Y1denCS3RbtVdDcOV7zt0Eg9eRsw%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/CAAWYfq3OWRdrJk_pHRjL%2BQCu1b_0Dj_V5tBnmm2sdC1fxsB%2BJQ%40mail.gmail.com.
