Newsgroups: php.internals,php.internals.win
Path: news.php.net
Xref: news.php.net php.internals:125477 php.internals.win:1297
Date: Sun, 8 Sep 2024 15:58:27 +0100 (BST)
To: "Christoph M. Becker" <cmbecker69@gmx.de>
cc: PHP internals list <internals@lists.php.net>, 
    internals-win <internals-win@lists.php.net>
Subject: Re: [PHP-DEV] Maintain Windows PHP dependency builds in a GH repo
In-Reply-To: <cca18b22-9bf4-41dd-9673-e654a5d76794@gmx.de>
Message-ID: <91e789ef-fd36-6a44-74ac-9998668b7fde@php.net>
References: <cca18b22-9bf4-41dd-9673-e654a5d76794@gmx.de>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
From: derick@php.net (Derick Rethans)

On Sun, 8 Sep 2024, Christoph M. Becker wrote:

> All these problems could be solved, or at least mitigated, by setting 
> up a Github repository for the dependency builds and the series files.

> The upload could be as simple as a cron'd `git pull` on the server.

All our websites, including PHP downloads, use the rsync server for 
this. That server has a GIT checkout, and then the Web servers rsync 
from there. This is superior because it means the *web servers* never 
need the GIT checkout, solving duplication and permission issues. It 
also means it is easy to set up mirrors (unofficial).

> The only potential drawback I see would be the size of the repository.

This is already a major issue for the normal PHP downloads, which 
currently sits at 15 GB.

> While I believe the new repo would be way smaller than our 
> distribution repo[1], and we might exclude vc11 and vc15 builds, it 
> may still be too large for practical handling.

> But in this case we can consider using Git LFS[2] which has been 
> developed to address this issue.

Github LFS isn't free though, once you get to large storage sizes (over 
1GB) [1]. I also found it really fiddly when using it. As it's not free, 
I don't think it qould qualify as something for using in an Open Source 
project.

I don't believe GIT is a good fit for versioning binaries. Not for this, 
nor the PHP distributions. I understand the history aspects are useful, 
but it's never been designed for keeping binaries. It's not a file 
management tool, but a source code tracking solution.

I also don't think Git LFS has been created for this either. It is 
useful for *large files* in a repository, not *large repositories*. 
Files can be maximum 2GB, which is plenty for DLLs and our releases.

[1] https://docs.github.com/en/billing/managing-billing-for-git-large-file-storage/about-billing-for-git-large-file-storage

> What do you think?  Would this require the RFC process?

I think it needs some good thinking through first. I also don't believe 
the RFC system is something we need to use for deciding how to serve 
files.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social