Grin: Provide 64 bits Mac and Linux binaries

[ignopeverell]

It shouldn't be too complicated at this point, but it implies a release process and schedule. I'm proposing to start with loose monthly releases. It's a good balance of frequency and by not setting a fixed date we give ourselves some latitude to move it by a week or two if it happens to be a bad time or unstable. This should include grin-miner.

It may be a little more controversial but we may want to include a kill switch after say 2 months. At least until mainnet.

Toughts?

[antiochp]

Kill switch as in the local binary itself stops running after a particular date?
Or is this possible (feasible or even desirable?) to do with a hardfork on the chain itself?

[yeastplume]

Makes sense to start getting into the habit. Are you thinking about automating this? Providing .deb or .pkg packages? I've also had issues in the past trying to use binaries from one distro on another.

[ignopeverell]

Haven't thought about automation yet, I was thinking that step 1 would be to try a build and see what are the portability issues.

@antiochp I was thinking about the binary stopping after say 3 months (for a 1-month release schedule).

[quentinlesceller]

Do we want to do deterministic builds such as gitian build (https://github.com/bitcoin-core/docs/blob/master/gitian-building.md) ?

[antiochp]

Yeah - I think having the binaries time limited makes a lot of sense.
Its just a communication issue to make sure users are clear that this is what they are signing up for initially.

[antiochp]

@quentinlesceller deterministic builds would be a nice thing to aim for.
I can't find the link now but I thought I'd read something about this being hard to do with Rust/Cargo though. Could be wrong though.

[quentinlesceller]

Ah yes I remember that too. This is what you are looking for @antiochp https://github.com/rust-lang/rust/issues/34902.

[ignopeverell]

Let's make that a goal eventually but not start with it. Right now a good first step would simply be to have 2 portable binaries.

[kargakis]

@stratakis can help with RPMs in Fedora once you start releasing binaries.

[mcdallas]

For distributing the binaries may I suggest keybase.io?

Each keybase user has a public folder using the keybase filesystem (kbfs). Everything you put in your public folder is automatically signed and there are public proofs that the key belongs to the owner (if you link your github account).

For example here is roasbeef's public folder with his signed lnd releases https://keybase.pub/roasbeef/ and here is his public proof

[yeastplume]

I'm doing something similar already in https://github.com/mimblewimble/grin-web-wallet already.

It should be possible to do this fairly simply via travis CI for a few target distributions and MacOS, so that release builds are triggered on every tag the resulting binaries are uploaded to to the github release. The .travis.yml file in grin-web-wallet gives an example of this (it's doing a node build but the process is the same). We just need to set up the matrix to build for a few different platforms somehow (without impacting the automated testing).

[garyyu]

Oh, It's not easy 😈
actually, imo, the easy label could not be a good idea to be used, anyone support me? 😺

[garyyu]

and the most difficult part is the test, each test spent about hour an hour and I have 29 times tests on this. Lucky it's almost done:)

[ignopeverell]

This I think is pretty much done. Just one last topic of discussion: Mac releases. @garyyu as we removed Mac builds from master, would tagging on a branch that has Mac builds enabled work?

[garyyu]

Doesn't work for mac at the moment. Current solution will double the Travis-CI test time for PR, so it has been disabled for mac.

It need occupy at least one test dedicated for mac platform but we already used all the allowed 5 parallel tests (free Travis-CI account allow maximum 5 parallel).

If don't want increase the Travis-CI test time for pull-request, we need a little bit more research on how to do that, I can contact Travis-CI to ask for help, if you still want Mac binary release.

[ignopeverell]

I do. But I'd be fine with having this not being automated and attached to the release after the fact. I just don't have a Mac to do this from, so it'd have to come from you or another Mac user.

[garyyu]

Ok, understand. I will complete it in this week.

[ignopeverell]

This is mostly fixed, remaining should be handled as separate tasks if deemed necessary.