Hi Vladimir,
On Sun, Oct 28, 2018 at 6:32 AM Vladimir Sedach vas@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.
Hence my idea that we need a means to manage those released files separately.
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.
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.
Vladimir
-
Erik Huelsmann -
Vladimir Sedach