You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SourceForge has experienced stability problems in recent years, which have at various times caused some of our releases to temporarily disappear (refer to #225) or have prevented me from uploading a new release (on multiple occasions.) Apart from archives of our pre-GitHub mailing lists and tracker items, the only thing we use SourceForge for these days is file releases. Multiple users have requested that we move our file releases to GitHub. However, that remains problematic for multiple reasons:
GitHub doesn't allow us to hide the source tarball and zip files that it auto-generates for every release. We provide our own official source tarball with each release and do not support using GitHub's auto-generated source code assets, so I would strongly prefer not to use GitHub for file releases until this is resolved.
SourceForge's file release system allows arbitrary directory structures and access via SSH and SCP. That allows me to push new releases and manage existing releases automatically from the command line as well as host a YUM repository under our SourceForge file release directory. GitHub has a command line utility for pushing and managing releases (although it isn't as versatile as SSH/SCP), but there is no way to host a YUM repository on GitHub.
I have looked into PackageCloud, but it unfortunately uses a different repository URL for every package architecture, whereas (for simplicity) we need to be able to host all package architectures under the same URL.
I have also looked into hosting a YUM repository by simply pushing the RPM files and YUM metadata to a normal GitHub repository, but the volume of data would likely violate GitHub's repository size restrictions.
I have looked into hosting a YUM repository on Amazon S3, but the cost of storage and bandwidth would likely be prohibitive given the popularity of this project.
I am OK with hosting a YUM repository on a site other than GitHub, as long as that site allows new packages to be pushed from the command line and is run by a reasonably stable company (at least as stable as SourceForge.) However, if I'm going to continue using SourceForge for YUM repository hosting, it doesn't make sense to stop using SourceForge for hosting other files. The idea behind this is to stop using SourceForge.
The text was updated successfully, but these errors were encountered:
libjpeg-turbo and TurboVNC have been migrated to GitHub and packagecloud. (I was able to make packagecloud work for our purposes, despite the architecture-specific URLs.) I will migrate VirtualGL next, so it should be available next week sometime.
SourceForge has experienced stability problems in recent years, which have at various times caused some of our releases to temporarily disappear (refer to #225) or have prevented me from uploading a new release (on multiple occasions.) Apart from archives of our pre-GitHub mailing lists and tracker items, the only thing we use SourceForge for these days is file releases. Multiple users have requested that we move our file releases to GitHub. However, that remains problematic for multiple reasons:
I am OK with hosting a YUM repository on a site other than GitHub, as long as that site allows new packages to be pushed from the command line and is run by a reasonably stable company (at least as stable as SourceForge.) However, if I'm going to continue using SourceForge for YUM repository hosting, it doesn't make sense to stop using SourceForge for hosting other files. The idea behind this is to stop using SourceForge.
The text was updated successfully, but these errors were encountered: