Hi, "[prompted by FUNDING issues!!!]" ???
Back in 2016, when cloud hosting was imposed over academic hosting, William promised "to pay for it indefinitely", see https://groups.google.com/g/sage-devel/c/ed_ya-d-k_E/m/jYoR6opODAAJ If only for this reason, there is no funding issue. The fact is that the the magic cloud ideology turned into a disaster, years after years, from askbot in 2014 (thanks again to Niles and OSU sysadmins for their involvement in its academic hosting during six years !), to the wiki a few months ago, and now trac+git. I have been involved in rescuing those services, and putting them back in a safe place. What do the facts tell us about academic hosting, in 2022 ? - askbot is academically hosted and works pretty well. Fees to the Sage community: 0$ per year - patchbot server is academically hosted and works pretty well. Fees to the Sage community: 0$ per year - I bet that most patchbot clients are run from academic desktops. Fees to the Sage community: 0$ per year - wiki is academically hosted and works pretty well. Fees to the Sage community: 0$ per year - the backup server (which currently backs up askbot and wiki) is academically hosted and works pretty well. Fees to the Sage community: 0$ per year - most download mirrors are academically hosted and work pretty well. Fees to the Sage community: 0$ per year For this reason also, and given the number of universities around the world, there is no funding issue. The rest is FUD. Ciao, Thierry On Fri, Sep 09, 2022 at 02:54:06AM -0700, 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. > > > > *) 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 "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/20220909144801.GA19110%40metelu.net.
