Closed mkoeppe closed 1 year ago
maybe git LFS would be a better way ?
I agree with @dimpase . It's certainly fine with me if that mirror server is used... but I wouldn't trust it! There's no backups, it's nearly a decade old, and it could randomly die at any moment.
moneywise, LFS is free for up to 1GB storage and 1GB bandwidth. else, extra 5$ p.m. buys you 50GB storage/bandwidth, so it's really cheap.
So would we create a new repo in the sagemath organization for that, with LFS enabled, or would we use our website repository or another existing one?
Speaking of the mirror server, perhaps we should also create retroactive Releases in sagemath/sage for historical versions of Sage, with the various tarballs as Release Assets?
+1 to using "Github Releases" -- in my experience they are great for binary (and source) releases. It solves some of the same problems as the current mirror server better and for free, as far as I can tell.
So would we create a new repo in the sagemath organization for that, with LFS enabled, or would we use our website repository or another existing one?
IMHO LFS can be used in the repository with the issues; e.g. on the current trial server in
sagemath/sage-all-2023-01-12-003
I don't think we want the LFS in our main Sage repository?!
OK, then a separate repo for archiving?
(did you look at these attachments? most are probably meaningless, such as large logs, binary dumps, etc, on closed tickets?)
Some of them are probably sage-src
ed tarballs such as the giac tarball.
So we may think about a solution that also is good for this use case in the future, not just these 12 historical attachments
On Fri, Jan 13, 2023 at 12:24 PM Dima Pasechnik @.***> wrote:
OK, then a separate repo for archiving?
(did you look at these attachments? most are probably meaningless, such as large logs, binary dumps, etc, on closed tickets?)
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
-- Dr. Matthias Koeppe . . . . . . . . http://www.math.ucdavis.edu/~mkoeppe Professor of Mathematics
Actually, I am not sure we really need large attachments, with versioning. trac
destroys older versions of attachments, as far as I know. I'd rather not have them at all, it's potentially prone to abuse - we don't want to police a repo for rougue videos and whatnot.
Makes sense. Let me take a closer look what those 12 attachments are and maybe there's a clear way how to deal with them. For example, for the giac tarballs we could put a fork of a giac repo in github.com/sagemath and then create fake releases. Then I can remap the 12 file URLs by hand.
Indeed 11 of the 12 are giac tarballs.
The 12th is an old jmol tarball on https://trac.sagemath.org/ticket/25026
send them to a museum 🤦🏽♂️ (or archive.org)
Well, that's what we're doing here, right? Curating a museum of old tickets
The GitHub importer rejects uploads of large
repository_file
s (> 25 MB).We have about 12 of those (between 25MB and the maximum size allowed on Trac (50 MB?). They need to find a new home. @williamstein @dimpase @vbraun Can we use the file server (origin of the Sage mirrors) for these?