January 2022 - clo-devel - mailman3.common-lisp.net

Ownership of CDR project/repos
by Marco Antoniotti 21 Jan '22

21 Jan '22

Hi I am listed as a developer for the CDR project/repos ( https://gitlab.common-lisp.net/cdr/cdr.common-lisp.dev/-/project_members) Could you list me as owner or maintainer? Thanks Marco -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

1 0

Pages not deploying?
by Raymond Toy 19 Jan '22

19 Jan '22

Not sure what happened but the pages for cmucl-site aren't actually deploying. For example, the pipeline https://gitlab.common-lisp.net/cmucl/cmucl-site/-/pipelines/5701 says the pages were deployed. If you download the artifacts and look at public/doc/index.html, you'll see that there's an entry for Hemlock docs. But when I visit https://common-lisp.net/project/cmucl/doc/index.html, the entry for the Hemlock docs is not there. This used to work, but I'm not sure what's changed. Also, a side note. If you browse the archive and navigate to public/doc and click on index.html, the URL is http://cmucl.pages.example.com/-/cmucl-site/-/jobs/26695/artifacts/public/d…, which doesn't exist. What can I do to make this work? -- Ray

5 18

Simplifying hosting services (aka "breaking up the monolith")
by Erik Huelsmann 13 Jan '22

13 Jan '22

Hi, In 2021, common-lisp.net has had two types of service interruptions: (1) mailing lists were not functioning correctly [while regular mail traffic seemed to be] an (2) deployment of project sites wasn't working. The latter only came to light recently, but seems to have existed for some time. Since I can remember (probably since the creation of the service) has common-lisp.net hosted its project webpages on its main domain in a sub directory, which at times has been called /project/, or /projects/ or even /p/. This setup mixes project hosting with hosting for the main site itself and restricts the tooling we can use to host the projects' websites. The reason for the sites not deploying well is that I've implemented a workaround in the past to be able to deploy projects using GitLab Pages while our deployment model (deploying to the /project/ subdirectory on the main domain) is out of line with what GitLab Pages were designed for. At the same time, our configuration is running with extensive sets of rewrite rules to keep historic URLs "working" and redirected to (hopefully) existing current URLs, which also extremely complicates our setup. In order to simplify our setup (and eliminate the deployment problems we're experiencing) and at the same time add support for requests like those from Marco who wants to be able to deploy sites for multiple projects under the same umbrella, I've decided I want to move projects' sites to their own (sub)domains. In the past I thought this would need to be subdomains along the lines of https://<project>.project.common-lisp.net/. Although that's a deployment model that would work with GitLab Pages, I've decided against it. I'll move the hosted projects to: https://<project>.common-lisp.dev/ (I acquired common-lisp.dev for this purpose this morning.) The setup I'm proposing is that we have a good look at the tons of rewrite rules we have currently in place and clean up the rewrite rules that we don't need anymore. Then, we create rewrite rules for the current project namespaces at https://common-lisp.net/project/<project>/ to map to https://<project>.common-lisp.dev/. There are a few projects which aren't using GitLab Pages to deploy their websites yet, mostly because they have no active maintainers. These projects will keep being served from their current locations on the filesystem of the common-lisp.net host, but their content will be available through the new <project>.common-lisp.dev URL space. Further change proposals in order to separate the mail flow for the mailing lists from the regular mail flow (and thereby further reducing integration between components) are upcoming, but I'll need to address one thing at a time (due to time constraints). Are there any comments, remarks, additions, things you want me to take into account with respect to the above? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

7 9

CDR - Looking for some people...
by Marco Antoniotti 03 Jan '22

03 Jan '22

Hi I would like to get in touch with the following people in order to restart the CDR process in a more structured way and with some support from current technology. In particular, as some of you may know, there is now a Zenodo community which can be used to give DOI to CDRs ( https://zenodo.org/communities/cdr) To this end, I am looking to connect with the following people, who may be listening in on this mailing list. These are people who, besides myself and Didier Verna, have authored some of the CDRs "up there": before just adding their work on Zenodo, I would like their permission, whatever license they may have added to their work. So, if you are in the list (and I know some of you are listening), please drop me a line; thank you. If anybody knows how to get in touch with someone on the list, please let me know as well. I know some of the people on the list can be contacted directly, but I am notoriously lazy :) Thank you. - Marc Battyani - Arthur Lemmens - Edi Weitz - Gregor Kiczales - Ingvar Mattsson - Tobias C. Rottweiler - Sam Steingold -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

1 0

Consolidating Repositories and Groups
by Marco Antoniotti 03 Jan '22

03 Jan '22

Hi It is that time of the year when there is some time to do some hacking. Looking at the CLNET repositories I manage, I noticed two things. The first one is that there may be a GitLab limit on the number of repositories that one can have under her/his name. The second is that I have several "legacy" repositories with their own "group" and some newer ones without. (Plus there is the issue of separate repositories for documentation, but I can live with that). Please bear with me. I am not a GitLab expert and I am not running the show. I would like to know how we could go ahead and make it possible to "consolidate" "projects" and "repositories" in CLNET GitLab. The idea would be to have something similar to Github "organizations". Is this something that you think could benefit CLNET? All the best Happy New Year -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

3 5