We wanted to start this engineering update by describing the work we’ve been doing on development methodology and processes. We continue to make steady progress towards improving transparency and openness when it comes to development practices, embracing community open source development model.
To that end, we have been migrating tasks and issues from JIRA, which is a closed development focused tracking/planning system to Github. Most tasks and issues are now in Github, and are open to the community to see and comment on. We have also added “projects” – Kanban boards representing the status of various sub projects: https://github.com/orgs/graft-project/projects
We have a number of tasks that are tagged as “help wanted” and are open to the community development, with GRFT rewards attached to them. You can pull up the “help wanted” tasks by running a filter. You can find the proposed community task guidelines here. We will be adding more community dev tasks in the near future.
If you know of capable SW engineers who would like to work on interesting problems and make a contribution to the project that has solid potential to improve the world, please refer them to the open community tasks.
Lastly on this subject, we would like to welcome to the team Nick Willson, @DaDudster on TG, who will help oversee the open source community development efforts at GRAFT. Nick comes to the project with extensive background in computer science, artificial intelligence, and a keen interest in the blockchain space. Nick has a PhD from RPI in Cognitive Science. Coordinating open source development is not a trivial task and we’re very happy that Nick stepped up to the challenge!
Here’s the recount of development progress over the past two weeks:
This is a significant upgrade that brings important new features and improvements to the network such as much smaller block sizes, multi-signature wallets, and better security.
The merge has been quite a bit of work and we’re excited to get this done as it paves the path to other network features on the roadmap.
Congratulations to the team and community. Thanks for the hard work!
You can find the latest 1.8.2 Release HERE
Updated: MAY 17, 2019
We’re very close on the merge release but still dealing with some last minute issues.
FWIW, the merge may sound easy, but it is an incredible amount of work – 100s’ of Monero unit tests have to pass and then GRAFT’s on top. Every change potentially has consequences in other places that have to be found and reconciled.
We’re getting there though. At this point we’re looking into next week for public Testnet.
We’re almost finished with the M13 merge – it has been a LOT of work – picking apart and putting back together a very complex and not that easy to follow code base that is Monero, following and retesting all the changes with the code we’ve added, but we’re pretty much there though with no blocker issues left at this point and only few non-blockers to get through.
Some devs are taking a break this week and part of next week for national and family holidays, so will push out the network update rollout until mid May when everyone’s back and are able to support any issues that might come up.
LYRA UpdateWe hit a big first milestone with LYRA DPoS architecture this week – a very early first proof-of-concept version was shown by Slava. LYRA combines delegated proof-of-stake (DPoS), private transactions, and chain collection (no single blockchain!). Why are we working on LYRA now?
There are several reasons for that: 1) we’re in the field that is developing extremely rapidly and favors projects that not only deliver the functionality, but also (and perhaps most importantly) offer technology leadership. 2) A DPoS architecture will be useful in different ways over time, starting tentatively as a sidechain solution for merchant tokens / loyalty programs.
- Fix Windows compile for libboost-1.69 (#266)
- Fix segfault while syncing blockchain (#271)
- Removed chatty debug messages while updating processing stake transactions (#272)
- fixed shutdown while processing requests (#260)
- changed error to warning for RPC requests from supernode to cryptonode during blockchain based list and stakes synchronization (#263)
Disqualification flow is a critical part of fair and optimum Supernode sample selection. Please review the current proposal and comment.