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

Tracking Issue: Launchpad Release #6522

Closed
4 tasks
ethanfrey opened this issue Jun 26, 2020 · 19 comments
Closed
4 tasks

Tracking Issue: Launchpad Release #6522

ethanfrey opened this issue Jun 26, 2020 · 19 comments

Comments

@ethanfrey
Copy link
Contributor

ethanfrey commented Jun 26, 2020

Summary

After much discussion about the upcoming Stargate (IBC + Protobuf) releases and Hub upgrade, it became apparent that we need to provide better support for all the chains running mainnets on pre-Stargate version. Thus the concept of Launchpad was created to help.

Problem Definition

Launchpad will be a LTS release, compatible with the 0.38.x series. We will backport a few critical DB performance fixes from master and then stabilize Launchpad. At that point, the only ongoing development should be (backporting) bug fixes. This will provide a stable version of the code that any existing chain can easily upgrade to.

The Stargate team will also ensure a well-tested and documented migration path from the Launchpad release to the Stargate release, and if everyone starts the journey to the Cosmos from the same place, it is much less likely to have unexpected issues when migrating existing chains.

We plan to tag the Launchpad release, hopefully by late July, and hope all mainnets can upgrade to it. It should be a simple recompile, restart for 0.38.x chains and a typical upgrade for 0.36 or 0.37 chains. We also ask wallets / explorers / etc to upgrade support to the Launchpad release (which should be non-breaking) and maintain this in parallel to any future Stargate work.

Proposal

We should get input from all Zones and Modules that aim to upgrade to launchpad to ensure the frozen feature set is acceptable to all. If you wish to add an issue or PR to Launchpad, please link it in a comment below. If it is accepted (still a bit unclear how this happens, but @okwme will help organize that), then it should receive a 0.39 LTS (Launchpad) label. We can see all items that belong to Launchpad here:

I propose that the list of "Launchpad" items be frozen end of day on July 6th, 2020, to give time to organize a stable release with it.

Once these are completed, we tag a release both with a version (eg. v0.38.6) as well as launchpad. All future releases on that line afterwards will have no breaking changes and no new features, only security updates and bugfixes. This should follow the definition of Stable Release, being defined here


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@ethanfrey
Copy link
Contributor Author

This PR from @alexanderbez is a major upgrade to DB stability and the concept has been generally accepted for Launchpad on Discord #6505

(It still needs reviews and testing, but definitely should be included in Launchpad)

@ethanfrey ethanfrey changed the title Launchpad Release Tracking Issue: Launchpad Release Jun 26, 2020
@alexanderbez
Copy link
Contributor

I think this is a phenomenal idea. What I'm still confused about is what exactly "launchpad" is? From my POV and the way I understand it, launchpad == 0.38.x, which already exists. Apart from the pruning fixes, what else do we want in 0.38?

@ethanfrey
Copy link
Contributor Author

This is one cherry pick that Fede proposed: #6523
It seems critical for Ethermint.

@alexanderbez 0.38.x should not have breaking changes. Launchpad should have everything to provide a complete, stable platform, as if we didn't dump tons of breaking changes on master as soon as 0.38.0 was cut and actively maintained and backported bugfixes.

0.38.5 is technically not 0.38.x as it is a breaking change, and since 0.39 is taken, we can't really use that number either.. this space between 0.38.x and a release suitable for most projects is "launchpad".

@Codegnosis
Copy link

Codegnosis commented Jun 30, 2020

I believe this already has a backport/release/v0.38.x label, but can I request it gets added to launchpad too (if not already flagged)? Issue #6306

Thanks.

@alexanderbez
Copy link
Contributor

I would prefer to stick with the backport label -- it has no semantical difference with launchpad.

@ethanfrey
Copy link
Contributor Author

ethanfrey commented Jun 30, 2020

Okay, I just saw the backport/release/v0.38.x label. Didn't realize you were using it for the same thing.

I just updated the links in the issue description

@ethanfrey
Copy link
Contributor Author

ethanfrey commented Jun 30, 2020

In addition to my PRs above, I would like it if we could consider better gas pricing / charging for transactions. After I made my "robust gas pricing issue" I realized this has been discussed many times. The following two seem quite actionable items:

It would be good to discuss if either (or both) could be in scope for launchpad. If they are, then discuss implementation.

Why I think this is important? Many clients have this issue with gas estimation. A few days ago this came up again in discord: https://discordapp.com/channels/669268347736686612/669274997264613376/727184290818949190 explaining how Ledger Live provides the gas estimate:

@okwme

Is this how all the wallets are dong this? Are the updates in 0.38 and 0.39 going to improve this process at all?

Ledger Live:

For the network fees before any transaction is sent :

  • The gas estimation for a transaction provided by gaia node does not simulate the gas cost of reading and writing to the tendermint database.
  • Therefore we have to apply a gas_amplifier factor to the estimation gaia gives us back, hoping that it will cover the storage costs.
  • We tuned this amplifier to have all transactions passing (we had lower values at the beginning, but internal testing triggered a lot of lost funds because of OutOfGas errors)
  • After this (safely high) GasWanted value is computed, we apply the anti-spam multiplier 0.25 uatom/gas and that's the "Network fees" value that you see

@ethanfrey
Copy link
Contributor Author

ethanfrey commented Jun 30, 2020

Beyond such a large task, there also seem to be a number of non-breaking bug fixes that could potentially be backported (correct me if some have been already):

Also this improvement seems simple: #5896

@alexanderbez
Copy link
Contributor

I've added a backport label to some of those issues, the ones I didn't add it to are either state-machine breaking or would be too much headache to cherry-pick. Thanks for taking a look and gathering those @ethanfrey.

WRT to the beefy two issues you've posted, yes, it would be ideal to get those implemented. But we don't have anywhere near the necessary bandwidth to do them atm. Not to mention, getting those into 0.38 would be...hard if not impossible assuming we're sticking with minor API breaking changes only.

@alexanderbez
Copy link
Contributor

alexanderbez commented Jul 2, 2020

Ok, had some more time to think about this. It seems the best thing to do is:

  1. Release 0.38.5 based solely off of 0.38.4 with any necessary security patches. We will not support this version line after this. DONE.
  2. Release 0.39.0 (launchpad (LTS)) which is 100% state-machine compatible with the 0.38 line, but includes pruning fixes, Tendermint update, along with any labeled backport issues/PRs (i.e. the launchpad/release/v0.39 branch will become 0.39.0).
    2a. Current PRs that have or will be added to launchpad.
  3. What was once being tracked as 0.39 (stargate) will now be tracked as 0.40.0.
  4. What was once being tracked as 0.40 (naming???) will now be tracked as 0.41.0.

@alessio
Copy link
Contributor

alessio commented Jul 2, 2020

Sounds like we have solid plan!

@Codegnosis
Copy link

Apologies - I referred to the wrong PR in my previous comment - the issue was the message.sender accumulation the Events, and the specific fix was in a comment within the tagged issue - #6306 (comment)

@clevinson
Copy link
Contributor

The label has been updated now to 0.39 LTS (Launchpad).

Currently there are PRs that Bez added labels to, and seem to have general agreement that they fit within launchpad:

This leaves the following issues unaccounted for from @ethanfrey's previous list:

Additionally, @ethanfrey mentioned that #4938 would be great to include, and offered to do a PR & backport for this if it gets approved for Launchpad.

Looking for thoughts from others here on scope (@alessio @aaronc @alexanderbez). Regen team is currently pretty heads down on 0.40/Stargate, and I'd like to keep it that way if possible. Is anyone else interested in trying to cherrypick these last unaccounted issues so they can be folded into Launchpad?

@alessio
Copy link
Contributor

alessio commented Jul 6, 2020

The label has been updated now to 0.39 LTS (Launchpad).

We should use https://github.com/cosmos/cosmos-sdk/milestone/27 instead of the label https://github.com/cosmos/cosmos-sdk/issues?q=label%3A%220.39+LTS+%28Launchpad%29%22+is%3Aclosed (I'm incorporating this into my PR re: stable releases)

@alexanderbez
Copy link
Contributor

alexanderbez commented Jul 6, 2020

@alessio the milestone and label are complimentary. They should be used together.

flow:

  1. PR lands on master
  2. We discuss that said PR should be backported (i.e. cherry-picked) into a point release (e.g. launchpad)
    2a. A label is added to said PR
  3. A PR is made with the cherry-pick against the living backport branch
  4. Finally, that PR (step 4), is added to the milestone so we can track it.

@alessio
Copy link
Contributor

alessio commented Jul 6, 2020

Ok that clarifies the scope. It makes sense. Thanks!

@ethanfrey
Copy link
Contributor Author

Additionally, @ethanfrey mentioned that #4938 would be great to include, and offered to do a PR & backport for this if it gets approved for Launchpad.

I want to repeat this here.. (on discord and some other chats already).

It is a major client issue. The only breaking part is clients needing to reduce the "gas multiplier" to a normal level (so inconvenience if not fixed, definitely not state-machine breaking). I will take it on, as it will vastly help with our attempts to estimate costs of cosmwasm contracts.

@alexanderbez
Copy link
Contributor

We're gonna get #4938 in 🎉

@clevinson
Copy link
Contributor

So in terms of launchpad, seems like we're aligned on @ethanfrey taking on #4938. I'm assuming will we move forward without the following pieces (from @ethanfrey's initial post):

alessio pushed a commit that referenced this issue Jul 14, 2020
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

6 participants