search

rncbc / drumkv1

drumkv1 - an old-school drum-kit sampler
https://drumkv1.sourceforge.io
GNU General Public License v2.0
35 stars 6 forks source link

Sourceforge is terribly unreliable for hosting releases/Add release artifact to github releases? #38

Closed simonvanderveldt closed 3 years ago

simonvanderveldt commented 4 years ago

Hi Rui,

We've been having a stready stream of CI failures testing the packages for Gentoo for your vee one suite because the downloads from sourceforge fail all the time. This has been going on for quiet some time with it happening once or twice every two weeks or so, which is bad of course but still sort of doable, but it's only gotten worse and it's now failing about about three times a week, which is of course very annoying. Of course this doesn't only apply to our CI, I'm unable to download any of the releases at the moment myself either. image

I'm not sure why the projects are still on sourceforge and I'm also not sure if you'd want to change them to be primarily hosted here on github? That might be the best fix. In case you want to keep the sourceforge pages and releases would it be an option to add the release archives to the tags/releases here on github as well? We've never had a single issue with projects hosted on GitHub.

rncbc commented 4 years ago

if you're doing any kind CI why you source on the release tarballs at all? wouldn't it best to source on the git source code repository ? it's always in sync with (my own) upstream (and to sf.net also, but nevermind that). that said, all releases are always tagged here as well: cf. https://github.com/rncbc/drumkv1/releases you may certainly opt to grab the release tarballs from there, although they get a slightly different filename, but that's not the point. please, be my guest, by all means.

simonvanderveldt commented 4 years ago

Thanks for the quick reply!

if you're doing any kind CI why you source on the release tarballs at all? wouldn't it best to source on the git source code repository ? it's always in sync with (my own) upstream (and to sf.net also, but nevermind that).

We do both. Gentoo is rolling release, so the CI for releases of packages is more to validate they still compile correctly within the ever changing environment :)

that said, all releases are always tagged here as well: cf. https://github.com/rncbc/drumkv1/releases you may certainly opt to grab the release tarballs from there, although they get a slightly different filename, but that's not the point. please, be my guest, by all means.

Yeah, we could indeed switch to using the automatically created release archives on github, but they are a 1:1 copy from the git sources, so for example they don't contain the configure script. What do you do when creating the release archives on sourceforge? Only run autoconf? Or also other things?

rncbc commented 4 years ago

What do you do when creating the release archives on sourceforge? Only run autoconf? Or also other things?

./autogen.sh

simonvanderveldt commented 3 years ago

Building from github works, we're just running the autotools part ourselves now :)