These updates are now categorized by working groups.
We’re still in the process of getting more of the working groups kick started but have been continuing the process of organizing the related development projects. We took some time this week to discuss some tickets still in the discussion phase of their respective projects and moved them to working-queue status.
As a reminder, the goal of the working groups is to eventually have regular, specialized meetings (with a designated note taker) so that each area of development can move forward more efficiently and provide meeting notes or reports of their recent progress to include in these updates.
At the beginning of the week, we had an engineering meeting focused on the preliminary hard fork (HF0). We focused on tickets with discussion and working-queue status in the HF0 project.
We ended up talking about #713 and came to agreement that refusing to rollback past a certain block depth would be included for HF0, however did not come to conclusion on what that depth actually should be, so it remains with discussion status. We also talked about #2286 and signalling/activation mechanism for hard forks. There was agreeance on using a bilateral hard fork approach which means that after a given block height, all future blocks will be required to follow new rules and are not acceptable by nodes who have not adopted new rules.
We postponed 1.0.9 release by 1 week so expect that to come out this upcoming Tuesday, May 23rd. Tickets expected to go into 1.0.9 can be seen in the milestone.
We’ve also settled on a continuous integration update release schedule which is offset from the client update release. The goal is to have development infrastructure upgrades released on the first Tuesday of each month (with client upgrades still happening on 3rd Tuesday of the month).
Most of the infrastructure engineering this week focused on finishing up a separate, development CI system which allows us to safely prototype changes to the dev infrastructure. Ticket #2302 is where to check for the final status of this.
As per the network performance issues from a few weeks ago, we’ve added a benchmark for connecting to an existing block with many inputs (PR 2372). Relatedly, we also started work porting our benchmarks to test upstream (Bitcoin 0.11.2) which will give us a better understanding of network and client behavior we’ve introduced vs behavior we inherited (#2356).
And as per our recent [release lifecycle process update0(https://z.cash/blog/release-cycle-and-lifetimes.html), we’ve added automatic shutdown for clients running deprecated versions (PR 2297).
Berkeley DB replacement:
No further discussions this week. See the Wallet DB to SQLite project for current status.
We discussed official support for a Zcash fork of bitcore which will provide third-parties with a wider array of development tools (#1534).
We had some internal demos of payment disclosure and XCAT this week. Both of these projects are moving along at a good pace now and we hope to have experimental versions ready very soon after further tweaks.
While not engineering related, a heads up that next week, the communications/business team at Zcash Company will be attending Consensus 2017 and TokenSummit in NYC and we’re set to be presenting at least a few times. Hopefully we’ll have some positive and productive outcomes from these events so keep an eye out!