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

Re: Proposal: project pages deployment through GitLab
by Erik Huelsmann 30 Oct '18

30 Oct '18

Hi Vladimir, Thanks for your reaction! On Mon, Oct 29, 2018 at 3:38 AM Vladimir Sedach <vas(a)oneofus.la> wrote: > [ .. snip .. ] > > This all seems like a very complicated way of hosting static files. I > think trying to do something as fundamental as that by forcing it > through a huge piece of software like Gitlab is a mistake. Six or > eight years from now, Gitlab is going to go out of fashion, the way > Trac has. If some people want to use Gitlab generated pages, that is > a valuable feature right now, but it is not going to be very future > proof. > > I use TRAMP and rsync to edit project pages and copy files and would > definitely prefer to have plain SSH and SCP. It was a lot easier to > transition project pages from HTML4 to XHTML to HTML5 with mobile > support than it would have been to move from SourceForge to Trac to > GitHub to Gitlab etc. Plain hosting also gives people the option of > using their preferred static site generator instead of Gitlab. > I see there's a bit of a misunderstanding going on and I apologize that I wasn't more explicit on what this change would mean. While you're probably correct about the move from SourceForge to Trac, there's definitely not something like that going on in the current proposal: you use TRAMP to build your static assets and you will keep doing that, even after deployment moves to GitLab. GitLab Pages is - from a user perspective - nothing more than a pipeline which specifies where the generated output is. That pipeline/CI job builds your static content using your own preferred static site generator (in case of c-l.net, that's some amalgamation of cl-markdown, plump, cl-who, etc. and in your case that's TRAMP). Building in this context can be as simple as "take the pre-built pages stored in a Git repository and declare those to be the build output". The additional bit that Pages does is to take the output from a CI build and deploy it on the Pages host. This last step simply means the pages become available as https://common-lisp.net/project/<some-project>/... In that sense, while GitLab Pages may not be the fashion of tomorrow, this isn't much of a problem because it's not dictating technology like Trac used to do and as such qualifies (to me) as plain hosting. Basically the only thing that changes is "plain (SSH) access" in the sense that GitLab does your deployment, not rsync or SCP. Is this how you understood GitLab Pages to work? If not, with this additional explanation, how do you feel about the proposal? Regards, Erik.

2 1

Projects without project page
by Erik Huelsmann 30 Oct '18

30 Oct '18

Hi, Working on cleanup this weekend, I found that roughly one quarter of all projects never replaced their auto-generated project page. These projects will likely (I have yet to find out) come in two groups: those which never got off the ground (no commits in source control) and those which simply didn't bother setting up a project page. I'm thinking to point the project page to the source repository (e.g. GitLab) when the project has sources, but doesn't have a project page. As for the projects which never spawned code, I'm wondering: should we simply remove those off the system (after contacting the project members, of course)? I mean, there's little Common Lisp value in them... Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

6 14

Re: Proposal: project pages deployment through GitLab
by Erik Huelsmann 29 Oct '18

29 Oct '18

Hi Vladimir, On Sun, Oct 28, 2018 at 6:32 AM Vladimir Sedach <vas(a)oneofus.la> wrote: > > Ok. Good. It's probably good to note that in my plans this type of > project > > page deployment will be the *only* supported way for project page > > deployment once introduced. (Given the little feedback I received last > time > > I pitched the idea, I thought it was a good idea to mention this fact.) > > > > I've analysed the content of some of the largest /project/*/public_html > > directories to prepare for this move. While we made a huge step in > reducing > > the content of public_html/ directories which wasn't really "site > content" > > (yet, rather Git or Darcs repositories), some of the largest ones are > using > > the public_html/ directory for binary artifact distribution (mostly > release > > binaries). I'll have a look at what we can do to support hosting that > kind > > of content (maybe with an artifact repository of some kind?) instead of > > depending on public_html/ for it. > > I'm not following. What exactly does "importing the current project > pages into GitLab repositories" entail, and why is that a problem for > release tarballs? Is it not just putting the static site files into > source control? > Yes, that's what it means. And for smaller numbers of tarballs that should be fine. However, there are projects which host all releases since 2003 on our site. Importing those into a Git repository would result in gigabyte-sized repositories. By themselves, having a Gigabyte sized repository isn't a problem, but having to download all releases since 2003 (3GB?) in order to make a site update isn't practical and something I want to put projects through. Once cloned, the project will even take double the space as the zip files are in the ref files as well as in the working directories of the git repository. Hence my idea that we need a means to manage those released files separately. > One other thing that should be preserved is hosting for user pages, > like https://common-lisp.net/~vsedach/ Ok. Would it be problematic for you if the user-space would be hosted/supported the same way as the project pages will? As in: your personal "site" can be dealt with through pushing to a git repository and the downloads managed through some means I yet need to figure out to deal with large(r) numbers of large files. I guess my question is: does your use-case get sufficiently covered by the solution I'm proposing? (And if not, can you provide more details so I can understand your use-case?) Regards, Erik.

2 1

Change of policy on GitLab account creation/login?
by Erik Huelsmann 24 Oct '18

24 Oct '18

Hi all, Almost 4 years have passed since the initial installation of GitLab on common-lisp.net. During that period, GitLab (the open source project) has seen tremendous growth both in user community and functionality. Our own GitLab instance has grown quite a bit as well. With almost 700 projects and nearly 500 users, it's quite a bit bigger now than the initial CVS migration which resulted in 379 projects and 395 users. (We did both the Git and Darcs migrations after that, which added to the growth.) Originally, we decided we wanted to create our own accounts and not support account-auto-creation (based on experience shared by GitLab.com) Today, GitLab lets itself be configured to auto-create accounts from GitHub using GitHub credentials. We have long supported the possibility of allowing accounts to be tied to Google and GitHub OAuth2 for the purpose of authentication. Additionally, we support 2FA these days. I'm wondering if we can be a bit more relaxed with account creation (allowing auto-creation), but be a bit more strict on account login: i.e. require 2FA. Do you have any opinion on the matter? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

3 5

[missing implementations]
by Daniel Kochmański 14 Oct '18

14 Oct '18

Hey, new website is great. There are though a few suprises: - clisp and lispworks are not listed in Resources -> Common Lisp Implementations - lispworks is not listed on getting started download page, but allegro is (since two free implementations are listed, it would be justified to mention two most popular commercial ones) Best regards, Daniel

8 16

GitLab now has 'reply by e-mail' enabled
by Erik Huelsmann 14 Oct '18

14 Oct '18

Hi, Today I found some time to enable GitLab's 'reply by e-mail' functionality. When you receive a notification e-mail from our GitLab instance, you can now send a reply to that notification. If the notification was from an issue being updated, then your reply will update the issue with a follow-up commont. Regards, Erik -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 2

Your opinion on my version of Common-Lisp.net website
by Mariano Montone 10 Oct '18

10 Oct '18

Hello everybody! I've been working on a new version of Common-Lisp.net website. Let me explain: I had an idea for a Common Lisp website. I was not happy with lisp-lang.org. So I started designing/developing. But then I came across Common-Lisp.net, and thought I could build on top of that instead. The result may be that my personal ideas and preferences may not be good for Common-Lisp.net mission in particular, or the maintainers taste. That's why I want your opinion on it. I'll be glad if some of it gets to replace some of the Common-Lisp.net site, but if not, I have not problem at all. My version of the site is hosted here: https://gitlab.common-lisp.net/mmontone/cl-site I started developing on top of this branch: https://gitlab.common-lisp.net/clo/cl-site/tree/more-scaffolding, that I found better than other branches. Can you guys try it and give me your opinion? To install: git clone https://gitlab.common-lisp.net/mmontone/cl-site make make serve This is what I've done: * Added Bootstrap themes from https://bootswatch.com/, which you can choose from (current one is Simplex) * Redesigned home page to include Planet Lisp and Reddit news in news sidebar. * Added Fontawesome icons * Redesigned Download, Community, and Documentation pages. * Added CL Implementations and Features pages. * Imported lisp libraries page from cl-awesome github project, and lisp-companies page from awesome-lisp-companies github project. Ok. Looking forward to hear your thoughts. Thanks! Mariano

3 5

Cleaning up common-lisp.net user database (not GitLab)?
by Erik Huelsmann 06 Oct '18

06 Oct '18

Hi all, common-lisp.net has 429 OS-level non-system users. Of these users, 347 didn't log in since 2013 (inception of the current instance). Just for the fun of it: cohorts since 2013: 1 2013 7 2014 18 2015 9 2016 10 2017 21 2018 Since these 347 users seem to get by without logging in (or have lost interest), I'm planning to remove these users and their home directories from the system as a system clean-up action. The GitLab accounts associated with these users won't be affected. Neither will project's public_html hosting associated with these users. Before removal of these accounts, all users will be notified through their @ common-lisp.net accounts which is expected to forward to a valid mail address. If a valid forward address isn't available, I'll be assuming we lost contact and there's no other option than to assume lost interest, followed by clean-up. This mail is both to notify as well as to solicit feedback. Any comments? Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 1

Moving project site deployment to GitLab CI (from upload through SSH)?
by Erik Huelsmann 05 Oct '18

05 Oct '18

Hi all, Today I've worked on figuring out how to (ab)use GitLab CI and GitLab Pages to set up the deployments for the content of https://common-lisp.net/project/* And I've found how to do that! Which means that we can start using GitLab and GitLab CI / GitLab Pages to allow people to deploy content to their hosting directories. As a site maintainer, I'd love to make this change. However, the site is here for its users. What do you think? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

Cmucl trac down
by Raymond Toy 16 Sep '18

16 Sep '18

Someone pointed out to me that trac.common-lisp.net/cmucl is not working. That returns an internal error: TracError: IOError: [Errno 13] Permission denied: u'/srv/project/cmucl/trac/log/trac.log' I have no need for trac to be running, except for being able to see old tickets. No new tickets, updates to tickets, wiki changes or anything else is needed since everything has mostly been migrated to gitlab. Well except tickets. trac seems to be available for other projects. -- Ray

2 1