On 08.09.2024 at 16:58, Derick Rethans wrote:
> On Sun, 8 Sep 2024, Christoph M. Becker wrote:
>
>> 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).
Thanks for the explanation!
> 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.
Oh, I wasn't aware of that.
> 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 agree.
> 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.
This is not about *how* to serve files, but rather *which* files to
serve; for instance, I'm currently working on updating libpng, where we
still ship v1.6.34 from Sep 29, 2017.
Anyhow, coming back to my list of problems:
(1) only few people can do these uploads
(2) the process is not transparent
(3) there is no history of the series
(4) the process is prone to error
If we only had the series files in a Github repository, (2) and (3)
would be solved, and (4) at least partially.
The workflow for updating a dependency might then look like:
* someone submits a PR with updates to the series files and a link to
the new dependency build on winlibs/winlib-builder (a PR template might
be useful)
* after some basic CI had been run, a notification is sent to those who
can do the uploads to downloads.php.net (or to the rsync server)
* one of these people can then check the PR, and if okay, upload the
dependency builds
* afterwards the PR is merged, and synced with the server
* archiving no longer needed dependencies could be done on the server (a
simple script should do; and it's not a very important task anyway, and
maybe it shouldn't be done at all, so that older Git revisions of the
series are still useable)
While that would not solve problem (1), it would at least avoid having
to ping some "random" people ("can you please upload?"), and if there is
an appropriate PR template, some further issues with problem (4) could
be resolved (e.g. do the series files refer to existing files?)
Cheers,
Christoph
