Skip to content

Conversation

@emberian
Copy link
Contributor

Welcome 👋

Thank you for contributing to Mina! Please see CONTRIBUTING.md if you haven't
yet. In that doc, there are more details around how to start our CI.

If you cannot complete any of the steps below, please ask for help from a core
contributor.

Incomplete Work

We feel it's important that everyone is comfortable landing incomplete projects
so we don't keep PRs open for too long (especially on develop). To do this we
don't want to forget that something is incomplete, don't want to be blocked on
landing things, and we don't want to land anything that breaks the daemon. We
don't want to forget to test the incomplete things whenever they are completed,
and finally we want to clean up after ourselves: any temporary cruft gets
completely removed before a project is considered done.

To achieve the above, we wish to keep track of incomplete work using a draft of
the release notes. We can share this part of the current draft at anytime with
external contributors. Moreover, we will review this draft during hardforks.

To ship incomplete work, put it behind feature flags -- prefer a runtime
CLI/daemon-config-style flag if possible, and only if necessary fallthrough to
compile time flags. Note that if you put code behind a compile time flag, you
must ensure that CI is building all possible code paths. Don't land something
that doesn't build in CI.

PLEASE DELETE EVERYTHING ABOVE THIS LINE


Explain your changes:
*

Explain how you tested your changes:
*

Checklist:

  • Dependency versions are unchanged
    • Notify Velocity team if dependencies must change in CI
  • Modified the current draft of release notes with details on what is completed or incomplete within this project
  • Document code purpose, how to use it
    • Mention expected invariants, implicit constraints
  • Tests were added for the new behavior
    • Document test purpose, significance of failures
    • Test names should reflect their purpose
  • All tests pass (CI will check this if you didn't)
  • Serialized types are in stable-versioned modules
  • Does this close issues? List them
  • Closes #0000

@mergify
Copy link
Contributor

mergify bot commented Mar 28, 2024

⚠️ The sha of the head commit of this PR conflicts with #15243. Mergify cannot evaluate rules on this PR. ⚠️

@mergify mergify bot mentioned this pull request Mar 28, 2024
@emberian
Copy link
Contributor Author

!ci-toolchain-me

@mergify
Copy link
Contributor

mergify bot commented Apr 2, 2024

⚠️ The sha of the head commit of this PR conflicts with #15243. Mergify cannot evaluate rules on this PR. ⚠️

georgeee and others added 26 commits April 3, 2024 18:42
…-2024-apr03

Fix HF unit test after compatible update
…ley-migration

Update nix files to build berkeley migration tools
* Make runtime_genesis_ledger stricter in accepting configs
* Remove nonsense from runtime_config when loading epoch_data ledgers
Problem: parameter is clearly redundant

Solution: take the value from the fork config
Problem: migration verifier tool and migration script incorrectly named
genesis config of the fork network as the fork config which introduced
certain confusion.

Solution: rename all such occurences of fork config to fork genesis
config.
@mrmr1993 mrmr1993 marked this pull request as ready for review June 10, 2024 16:34
@mrmr1993 mrmr1993 requested review from a team, bkase, mrmr1993, nholland94 and psteckler as code owners June 10, 2024 16:34
@mrmr1993
Copy link
Contributor

!ci-build-me

@mrmr1993
Copy link
Contributor

!approved-for-mainnet

@mrmr1993 mrmr1993 merged commit 012bc84 into master Jun 10, 2024
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

Successfully merging this pull request may close these issues.