Move Releases to Github

[super3]

Just wanted to raise some discussion. Is it possible that we could transition our releases to Github.

I think it makes sense to consolidate releases here both for convenience and other reasons. But then again there might be some reasons for continuing to use sourceforge that I might not be aware of.

[laanwj]

An added advantage of switching to github for releases would be https downloads.
I don't really see a drawback.

[luke-jr]

I think we'd lose download statistics?

[super3]

I'd trade that for simplicity and security. Think that is not really important anymore since we have a handful of alternate wallets too. I just pinged @github to see if download stats are possible.

[laanwj]

@luke-jr Looks like there are download statistics on releases posted to github (in contrast to "source tarballs"):

https://github.com/jhclark/multeval/downloads

[gavinandresen]

Only reason we were still at SourceForge for downloads was because github wasn't supporting big binary downloads, switching to github for the 0.9 release sounds like a fine idea to me.

[laanwj]

Agreed @gavinandresen . Here the process of creating github releases is described, seems pretty straightforward: https://github.com/blog/1547-release-your-software

I did hear there are some limits with regard to file sizes and total storage, but I can't find definitive numbers, and as the releases feature is brand new they don't appear to have updated their faq (https://help.github.com/articles/what-is-my-disk-quota) yet.

[luke-jr]

Did GitHub re-introduce downloads? Last I heard, they were retiring them and they'd be disabled entirely at some future time...

[super3]

@luke-jr Yeah they depreciated downloads a while back, but recently they introduced releases which is what @laanwj and I linked to.

[gmaxwell]

Seems like a no-brainer improvement if github really brought this stuff back. (people trusting a random third party's SSL for this is really concerning— they should be checking the signatures provided by the package, but I doubt it could make anything worse at this point).

(Though I do wonder when we're going to have hosts become uncomfortable with the size of the bounty we're creating for hacking their services…)

[laanwj]

The problem is that it's pretty hard for users that are not used to GPG to check the current signatures. I suppose we could package gitian downloader but that won't help initial downloaders.

Both Windows and MacOSX provide ways to sign downloaded packages/executables, maybe we should look into that. Though I remember that the issue was deterministic gitian builds :/

And it's a pity .tar doesn't have signature support or we could do the same for Linux (.zip files can be signed using a manifest, but as decompression tools don't really check this by default it's kind of pointless).

In any case, indeed github won't make this problem worse, it doesn't matter whether we trust github or sourceforge in this regard...

[laanwj]

Releasing on github could also solve #2476 (no separate source tarball download available) as github automatically packs up the state of the tree when generating a release.

[super3]

Ok. Well I guess we will do this for 0.9 then. If we encounter any unseen problems, we can just fallback to Sourceforge. Should we also post the previous releases on Github as well, or just post 0.9?

[DavidAJohnston]

I'd be in a favor of posting previous releases to Github for consistency sake, if there aren't any technical reasons not to.

[laanwj]

We moved away from sourceforge, but to hosting the executables directly on bitcoin.org instead of github. Closing this.