<div dir="ltr">Hi Vladimir,<br><div><br><div class="gmail_quote"><div dir="ltr">On Sun, Oct 28, 2018 at 6:32 AM Vladimir Sedach <<a href="mailto:vas@oneofus.la">vas@oneofus.la</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Ok. Good. It's probably good to note that in my plans this type of project<br>
> page deployment will be the *only* supported way for project page<br>
> deployment once introduced. (Given the little feedback I received last time<br>
> I pitched the idea, I thought it was a good idea to mention this fact.)<br>
><br>
> I've analysed the content of some of the largest /project/*/public_html<br>
> directories to prepare for this move. While we made a huge step in reducing<br>
> the content of public_html/ directories which wasn't really "site content"<br>
> (yet, rather Git or Darcs repositories), some of the largest ones are using<br>
> the public_html/ directory for binary artifact distribution (mostly release<br>
> binaries). I'll have a look at what we can do to support hosting that kind<br>
> of content (maybe with an artifact repository of some kind?) instead of<br>
> depending on public_html/ for it.<br>
<br>
I'm not following. What exactly does "importing the current project<br>
pages into GitLab repositories" entail, and why is that a problem for<br>
release tarballs? Is it not just putting the static site files into<br>
source control?<br></blockquote><div><br></div><div>Yes, that's what it means. And for smaller numbers of tarballs that should</div><div>be fine. However, there are projects which host all releases since 2003 on</div><div>our site. Importing those into a Git repository would result in gigabyte-sized</div><div>repositories. By themselves, having a Gigabyte sized repository isn't a</div><div>problem, but having to download all releases since 2003 (3GB?) in order to make</div><div>a site update isn't practical and something I want to put projects through.</div><div>Once cloned, the project will even take double the space as the zip files are</div><div>in the ref files as well as in the working directories of the git repository.</div><div><br></div><div>Hence my idea that we need a means to manage those released files</div><div>separately.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

One other thing that should be preserved is hosting for user pages,<br>
like <a href="https://common-lisp.net/~vsedach/" rel="noreferrer" target="_blank">https://common-lisp.net/~vsedach/</a></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">Ok. Would it be problematic for you if the user-space would be hosted/supported</div><div class="gmail_quote">the same way as the project pages will? As in: your personal "site" can be</div><div class="gmail_quote">dealt with through pushing to a git repository and the downloads managed through</div><div class="gmail_quote">some means I yet need to figure out to deal with large(r) numbers of large</div><div class="gmail_quote">files.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I guess my question is: does your use-case get sufficiently covered by the</div><div class="gmail_quote">solution I'm proposing? (And if not, can you provide more details so I can</div><div class="gmail_quote">understand your use-case?)</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Regards,</div><div class="gmail_quote"><br></div><div class="gmail_quote">Erik.<br></div><div class="gmail_quote"><br></div></div></div>