Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

0.9.30 Release #6311

Closed
chadyj opened this issue Oct 15, 2018 · 92 comments
Closed

0.9.30 Release #6311

chadyj opened this issue Oct 15, 2018 · 92 comments

Comments

@chadyj
Copy link
Contributor

chadyj commented Oct 15, 2018

This is an issue to list and discuss remaining issues for the 0.9.30 release.

Remaining issues can be viewed with the release tag.
https://github.com/status-im/status-react/labels/release

The 0.9.30 release has several improvements for #cryptolife and Devcon.

Using this issue to manage the release as team comms are split between Status and Slack
cc @status-im/clojure @rachelhamlin @andytudhope @annadanchenko @lukaszfryc

@chadyj chadyj added the release label Oct 15, 2018
@chadyj
Copy link
Contributor Author

chadyj commented Oct 15, 2018

Conversation about scope from Slack:

rachel / Dense Immaterial Mantis [17:57]

Here’s what would be nice, if we can address in the limited time that we have:

  • Ropsten support for Gitcoin trophies—Gitcoin team said they’d deploy to testnet on Friday 12/10
  • Addition of a network list to the HTTP server (no issue yet)

We will not change the URL for Bounties Network to prague.bounties.network, but we can do a quick test of the DApp. Bounties Network ran smoothly at ETHBerlin so let’s hope for the best.

Andy:

  1. Registration DApp: https://github.com/status-im/hackathon-registration-dapp (will be ready to test this week)
  2. Sidechain with POA/DAIChain integrated into RPC connections (cc @goranjovic @adamb for how theire experiments are going there)
  3. prague.bounties.network tested (Simona will provide stuff to test against by the 12th)
  4. Gitcoin kudos integration (Julien, Rachel and I are tracking that, will hopefully have code to test against by the 12th).
  5. Extensions and JS API working well in Status (@jeluard and @Rachel / Dense Immaterial Mantis to discuss that)
  6. Might need something specific for @divan's work on Whisper visualisation w/ Alethio, but doubt it.

@andytudhope @rachelhamlin Where are we on the move items? If there are issues can you please add the release tag or create issues?

The release was supposed to be cut tomorrow so please indicate which ones are must-haves and which ones are optional.

cc @divan @jeluard @goranjovic @adambabik mentioned above ^

@chadyj
Copy link
Contributor Author

chadyj commented Oct 15, 2018

0.9.30 releases updated here in the release notes doc.

@adambabik
Copy link
Contributor

Do we have a nightly or a build which has that sidechain configured? I checked the RPC endpoints for some popular methods and they were fine but I don't have a full suite to test everything.

@rachelhamlin
Copy link
Contributor

ENS entry point from the profile screen, with updated URL. Assuming the release will happen on the 22nd, we should have the DApp in shape by then.

In the nightly & tested.

HTTP server fix from @Andrey - #6228

This is small. Team is prioritizing extensions work, but this will actually be @alwx and he's planning to take a look later today.

Extensions work from @jeluard

Will tag relevant issues; Nastya is testing.

Sidechain/RPC connection from @goranjovic - #6250

I'm not sure about this.

Ropsten support for Gitcoin trophies—Gitcoin team said they’d deploy to testnet on Friday 12/10

There are some issues with the display of these tokens. If we can't get a PR in today, probably will have to drop it.

Addition of a network list to the HTTP server (no issue yet)

Not required.

@chadyj
Copy link
Contributor Author

chadyj commented Oct 15, 2018

Do we have a nightly or a build which has that sidechain configured? I checked the RPC endpoints for some popular methods and they were fine but I don't have a full suite to test everything.

I don't believe so. @goranjovic?

@chadyj
Copy link
Contributor Author

chadyj commented Oct 15, 2018

Update from release sync:

The team is aiming to cut the release end of day Tuesday Oct 16. Please try to get your PR's merged before then.

Also thanks in advanced to the team for getting this issues done quickly, reviewing quickly, and testing quickly. Cheers!

@chadyj
Copy link
Contributor Author

chadyj commented Oct 15, 2018

Ping @j-zerah @kimjf for release notes

@goranjovic
Copy link
Contributor

We have a PR with the heavy lifting needed for the sidechain change (#6260). With it merged, I can post the PR that actually adds those sidechains.

@yenda
Copy link
Contributor

yenda commented Oct 15, 2018

Regarding mailservers:

Previously the app was blindly firing requests for all topics. It was using some heuristics to guesstimate when the mailserver was done sending the requests based on how much time has passed since the last expired message arrived (mailserver send expired messages, in the sense that the whisper network would have considered these messages expired and discarded them).
The problem with that approach is that there is now a timeout on requests and after that timeout expires, the mailserver stops sending messages (to confirm @pilu @adambabik).
This means that with the current approach, not only does the app tells the user it is fetching messages when it is actually done for up to 10 seconds, but also some of the history might never be fetched.

Recently signals were introduced to notify status react when a request is completed (all messages for the request have been confirmed to be received) or expired (the timeout, 10 sec by default, has been reached before all messages could be sent). I made a couple of PRs that started using these signals instead of the heuristic mentioned in the previous point. However this PR has made a few underlying problems more visible:

  • we can only request one topic per request (soon fixed by @pilu PR and will require PR on status-react to use it, this will allow us to greatly reduce the number of requests when the user have many chats (only 1 request for n chats per day instead of n). release blocker
  • mailservers that are far away are timing out a lot. For America, Europe and Asia this is less problematic because they can luckily find their local server or manually select it, but other part of the world will have terrible history retrieval performances. My guess is that there is some kind of acknowledgments and waiting between messages sent so the higher the ping the more likely the request is to timeout before all the messages have been sent. This is a release blocker IMO. We need to find why the mailserver is so slow at sending messages, if it waits for some kind of acknowledgement or something.
  • desktop is not handling lots of loaded message well, this is very visible when fetching seven days of history as my last PR does (better to restart after the week of history has been fetched because the app becomes very irresponsible). This can also be reproduced by scrolling up in a few chats that have a lot of history (I mean scrolling up to the first messages which will take quite some time). We should also try to find a fix for that asap but I don't think it is a release blocker.

@gravityblast
Copy link
Member

The problem with that approach is that there is now a timeout on requests and after that timeout expires, the mailserver stops sending messages (to confirm @pilu @adambabik).

@yenda the timeout is only a client-side timer in status-go. after 10 seconds it's fired if the client hasn't receive the response yet.
The mail server itself never times out. It receives the request, it sends messages 1 by 1, and at the end it sends the "response" message.
This means that even if status-go fires the timeout, the server can continue to send messages.

@lukaszfryc
Copy link
Contributor

we can only request one topic per request (soon fixed by @pilu PR and will require PR on status-react to use it, this will allow us to greatly reduce the number of requests when the user have many chats (only 1 request for n chats per day instead of n). release blocker

@yenda the PR in status-go is already merged. I added an issue for you to use it in status-react #6334

@lukaszfryc
Copy link
Contributor

mailservers that are far away are timing out a lot. For America, Europe and Asia this is less problematic because they can luckily find their local server or manually select it, but other part of the world will have terrible history retrieval performances. My guess is that there is some kind of acknowledgments and waiting between messages sent so the higher the ping the more likely the request is to timeout before all the messages have been sent. This is a release blocker IMO. We need to find why the mailserver is so slow at sending messages, if it waits for some kind of acknowledgement or something.

@yenda was it always like this or we introduced it somehow recently? If the upcoming release does not introduce regressions in this area I'd say it's not a release blocker. Anyway, it's worth to fix asap.

@chadyj
Copy link
Contributor Author

chadyj commented Oct 16, 2018

Team, with the recent mail server issues and reports of reliability problems we will need to delay this release until we are absolutely certain Status is working reliably.

At the Hackathon and Devcon we are showcasing Status to the wider community so performance has to be flawless, and we should take the time to ensure this.

@lukaszfryc
Copy link
Contributor

@chadyj is it final decision? How about registration dapp and other things mentioned by @rachelhamlin (#6311 (comment))? I suppose we can cherry pick at least some of them if we won't make a normal release.

@chadyj
Copy link
Contributor Author

chadyj commented Oct 16, 2018

Hey @lukaszfryc it wasn't a decision but an observation. There are several existing release issues that are still open, plus the new mail server issues. Although if there are ways to remedy the issues, salvage the release and have a quality build for hackathon/devcon then lets do it.

@lukaszfryc
Copy link
Contributor

I'd say let's aim for the standard release but with a 1 or 2 days delay, submitting the iOS build on Monday.

Backup plan: cherry pick and release only couple of changes like the registration app to support the hackaton. But, I'm not sure which PRs we will be able to cherry pick as many of them may be dependent on on things that are already in develop branch.


cc @chadyj @annadanchenko @rachelhamlin @andytudhope.

@rachelhamlin
Copy link
Contributor

Makes sense.

In the event that we cherry-pick, I learned there's one more item that marketing needs:

And this item for ENS support is not listed in the must-haves above, but would also need to be included:

@chadyj
Copy link
Contributor Author

chadyj commented Oct 16, 2018

I propose that we remove Instabug from this release too. It doesn't pass the test as essential software and can expose us to security or privacy incidents. I added the release tag but if anyone feels we should keep it then please holla #6346

@chadyj
Copy link
Contributor Author

chadyj commented Oct 18, 2018

Update:

We have 3 PR's left.

Everything is assigned and in progress.

If all goes well we can cut the release tomorrow and start testing.

@chadyj
Copy link
Contributor Author

chadyj commented Oct 18, 2018

Yenda:

mailservers that are far away are timing out a lot. For America, Europe and Asia this is less problematic because they can luckily find their local server or manually select it, but other part of the world will have terrible history retrieval performances. My guess is that there is some kind of acknowledgments and waiting between messages sent so the higher the ping the more likely the request is to timeout before all the messages have been sent. This is a release blocker IMO.

Pilu:

the timeout is only a client-side timer in status-go. after 10 seconds it's fired if the client hasn't receive the response yet.
The mail server itself never times out. It receives the request, it sends messages 1 by 1, and at the end it sends the "response" message.
This means that even if status-go fires the timeout, the server can continue to send messages.

@yenda @pilu Is there action required for this? Next steps?

@goranjovic
Copy link
Contributor

The remaining PR for sidechains is here #6388

@mandrigin
Copy link
Contributor

Just a small note that it is so much easier to track everything here than in Slack.

@chadyj mailserver timing out doesn't mean that you won't receive all the messages anyway, because, as I understand, it is not a p2p timeout, it is our waiting time to receive all the messages.

@gravityblast
Copy link
Member

@chadyj we already fixed these things in the last days in status-go. Now the mail server sends back an error message, and envelopes can be packed in single messages. The client-side timeout is still needed though in case the mailserver doesn't send the response or in case of connectivity problems

@mandrigin
Copy link
Contributor

I think we need to calculate timeout starting from the last message received from the mailserver and not from the actual request time. Maybe we also might want to show how many messages are received.

@annadanchenko
Copy link

annadanchenko commented Oct 19, 2018

looks like more extensions PR will need to be added according to @jeluard :

jeluard [10:12]
We are still missing some bits for extensions otherwise they are essentially unusable..
Also need to push one PR to add kickback to the DApp list

@chadyj
Copy link
Contributor Author

chadyj commented Oct 19, 2018

@jeluard @rachelhamlin Help us out and tag any essentials with the release tag as well as ping us in this thread.

@chadyj
Copy link
Contributor Author

chadyj commented Oct 19, 2018

Have another release issue #6402
Can someone please grab that?

@jeluard
Copy link
Contributor

jeluard commented Oct 19, 2018

@chadyj Already tagged, will tag more. I'll let you know once everything is out

@jeluard
Copy link
Contributor

jeluard commented Oct 19, 2018

@chadyj @alwx is on #6402

@goranjovic
Copy link
Contributor

goranjovic commented Oct 23, 2018

regarding #6250 - we can bypass the upgrade decryption problem if we don't include the migration to add two sidechains to the existing accounts. In practice, this would mean that hackaton participants who want to use the sidechains would have to use a new account (but at least they would be able to do that)

wdyt @annadanchenko @andytudhope ?

@chadyj
Copy link
Contributor Author

chadyj commented Oct 23, 2018

regarding #6250 - we can bypass the upgrade decryption problem if we don't include the migration to add two sidechains to the existing accounts. In practice, this would mean that hackaton participants who want to use the sidechains would have to use a new account.

Sounds like a decent trade off to get this release shipped.

@goranjovic
Copy link
Contributor

@chadyj Ok, I'll remove the migrations then.

@yenda
Copy link
Contributor

yenda commented Oct 23, 2018

@goranjovic maybe there is a bug in the migration ?

@rachelhamlin
Copy link
Contributor

So this PR should solve both #6460 + #6438: #6488

But build process is delaying us, per Ragged Understated Loon. 😕

@pablanopete
Copy link
Contributor

regarding #6250 - we can bypass the upgrade decryption problem if we don't include the migration to add two sidechains to the existing accounts. In practice, this would mean that hackaton participants who want to use the sidechains would have to use a new account (but at least they would be able to do that)

wdyt @annadanchenko @andytudhope ?

also agree this won't be a problem because xDaichain is a brand new side chain so people won't have any tokens in it before the hackathon anyways very likely - creating a new account is a bit of a UX slowdown but also agree to get it in release shipped and since it's blocking old accounts it makes sense.

@annadanchenko
Copy link

@rachelhamlin is there anything to be changed in the mobile app for ENS usernames? like linking to the Dapp url on mainnet ?

@chadyj
Copy link
Contributor Author

chadyj commented Oct 24, 2018

We are 2 days away from the Hackathon and so really have to wrap up this release today. People will also be traveling so availability will be limited.

The de-duplication work is being done so thanks @janherich @rasom for making it a priority. Please yell out if you are blocked or can't get this done in a few hours.

@goranjovic do you expect to wrap up the sidechain issue this morning, or should we drop it from the release?

@rachelhamlin @jeluard are things all set for extensions?
When is ENS launching on Mainnet? AFAIK it still needs to be tested in the release

@j-zerah @kimjf Are you all set with release notes?

If things aren't in a good spot by 12CEST we should jump on a call and discuss how to proceed.

@annadanchenko
Copy link

@goranjovic @chadyj despite known non-critical issues I propose to merge #6388 and document known issues in release notes. see them in #6388 (comment)

@jeluard
Copy link
Contributor

jeluard commented Oct 24, 2018

@chadyj Everything is ready for extensions.

Let's 🚢 🚢 🚢

@rachelhamlin
Copy link
Contributor

@chadyj @annadanchenko nothing to change in status-react. The entry point on the profile screen links to names.statusnet.eth.

The ENS contract still needs to be deployed to mainnet, which will require a change with the names.statusnet.eth ENS resolver, but nothing more to do in Status to support this.

We're aiming to have this done today, so it will happen ahead of the release.

@rachelhamlin
Copy link
Contributor

We've tested the ENS DApp thoroughly on Ropsten and as soon @bgits or @3esmit deploys the contract to mainnet, will test there as well.

@chadyj
Copy link
Contributor Author

chadyj commented Oct 24, 2018

⚡️⚡️⚡️All the outstanding release issues have been closed. ⚡️⚡️⚡️

The release build can be downloaded from jenkins for testing.

However the Testflight upload failed complaining about Invalid username and password combination. @mandrigin @jakubgs Can you please take a look?

@chadyj
Copy link
Contributor Author

chadyj commented Oct 24, 2018

Roman fixed (thanks) the Fastlane issue and build 11274 is ready for testing in Testflight. ⚡️⚡️⚡️

@kimjf
Copy link

kimjf commented Oct 24, 2018 via email

@chadyj
Copy link
Contributor Author

chadyj commented Oct 24, 2018

I noticed one issue in the TF version where messages are not ordered properly. Older messages are shown before newer messages.

screen shot 2018-10-24 at 2 26 44 pm

@yenda Fixed a related ordering issue today on desktop. Same cause?

@jeluard
Copy link
Contributor

jeluard commented Oct 24, 2018

@chadyj I have this issues for days. Probably not a recent regression.

@rachelhamlin
Copy link
Contributor

@kimjf no stress, already written! Coordinating with Jonny on the posts.

@annadanchenko
Copy link

annadanchenko commented Oct 24, 2018

test team is very close to complete regression testing on the last release build. So far, no blocking issues found. In ~30 min we expect to complete testing and potentially we are OK to release.

@chadyj when do we want to release it? On TestFlight it's 11274 in 0.9.30. For Android: https://ci.status.im/job/status-react/job/release/job/release%252F0.9.30/24/artifact/pkg/StatusIm-181024-080818-46d265-release.apk cc @mandrigin

@yenda
Copy link
Contributor

yenda commented Oct 24, 2018

@chadyj it is not the same cause because the cause on desktop wasn't related to mobile at all. I think it is because the timestamp of chats isn't based on last message but time when the last message was received in the chat, so when receiving messages from inbox the chats are ordered based on when the last message was received from there

@chadyj
Copy link
Contributor Author

chadyj commented Oct 24, 2018

Nice one @annadanchenko and team!

If everything looks good let's shoot for 10am CEST tomorrow! 🌮

We will use 11274 in TF and 11274 in Google Play currently in the internal test track.

@rachelhamlin
Copy link
Contributor

Didn't realize this was already approved by Apple! Nice job, everyone!

Might be preferable to release later in the day, from a product perspective.

We just deployed the ENS contract to mainnet, and Barry is making a few last changes to the DApp before we can test on mainnet.

Once 0.9.30 is live & announced, people will know they can register names. @asemiankevich and I will test the DApp as soon as the latest is deployed today, but more buffer might be good. We were initially thinking we'd announce around 9 ET tomorrow.

@j-zerah thoughts from a marketing perspective? There is a blog post for both 0.9.30 and for ENS, and Blonde is also making a PR about ENS.

@rachelhamlin
Copy link
Contributor

Update: ENS DApp works well in my run-through of each core flow, but there's one tiny and fatal issue. The price is wrong below the fold on the first screen.

This requires attention from both @bgits and @3esmit to re-deploy the DApp, once fixed. After speaking with @j-zerah, think it makes sense to target 3 pm CEST to release 0.9.30.

@annadanchenko @chadyj

@annadanchenko
Copy link

@chadyj @mandrigin 11274 build is in Ready to Submit state that looks like it wasn't submitted to review. Can you send it to review if it's so, please?

@annadanchenko
Copy link

nevermind, just did it myself and got approval right after this

@mandrigin
Copy link
Contributor

done. approved. "testing"

@rachelhamlin
Copy link
Contributor

Latest version of the ENS DApp is deployed, now we need Ricardo to update the ENS URI to contain the new IPFS hash.

He should be landing in Prague soon, but I think we should push the release back one more hour to 4 PM CEST to be safe.

@chadyj
Copy link
Contributor Author

chadyj commented Oct 25, 2018

0.9.30 is released!

https://our.status.im/v0-9-30-release-extensions-ens-security/

Our Status
The Status Hackathon - #CryptoLife is taking place in Prague this weekend (October 26 - 28), so this release goes out to the developers who will be hacking with us both at the event and around the world.ExtensionsBuilding a DApp? You can now extend Status functionality to make your

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests