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

Agenda: Development, Apr 14 2020 #273

Closed
1 task
lehnberg opened this issue Apr 2, 2020 · 1 comment · Fixed by #282
Closed
1 task

Agenda: Development, Apr 14 2020 #273

lehnberg opened this issue Apr 2, 2020 · 1 comment · Fixed by #282
Labels
development Anything related to development meetings Anything related to meetings

Comments

@lehnberg
Copy link
Collaborator

lehnberg commented Apr 2, 2020

Solicit suggestions for agenda items for the Development meeting to be held on Tuesday Feb 18 @ 15:00 UTC in grincoin#dev channel on Keybase. Please comment to provide topics or suggestions.

Proposed agenda

  1. A yeasty reminiscence
  2. Agenda review
  3. Action point follow ups from previous meetings
  4. Status of Grin v4.0.0
  5. Becoming more soft-fork ready
    • What's grin's position on soft forks?
    • If soft-fork friendly, what (if any) changes would be required?
    • Unknown kernels
  6. How to handle upgrades after 5.0.0
  7. /packaging & releasing
  8. Other questions
@lehnberg lehnberg added meetings Anything related to meetings development Anything related to development labels Apr 2, 2020
@lehnberg
Copy link
Collaborator Author

lehnberg commented Apr 8, 2020

Following this forum thread, I'd like to add a point to discuss our future stance on soft forks / making grin more soft-fork ready:

@DavidBurkett writes:

If we’re going to take the stance that softforks are hacks, and hardforks should be used when possible, then we’ll want to plan for more frequent hardforks. If instead we decide they’re a useful way to apply backward-compatible updates, we may choose to try avoiding hardforks at all costs.

In terms of technical implications, @tromp writes:

We need to decide how to treat blocks with unknown header version,
and kernels with unknown features. Some soft-forking is possible by accepting either, but care must be taken that the latter is properly deserialized and that signatures are still verified as much as possible.

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

Successfully merging a pull request may close this issue.

1 participant