Author: Jeff Garzik 2015-09-15 04:10:37
Published on: 2015-09-15T04:10:37+00:00
The goal of moving consensus state and code to a specific, separate library (libconsensus) is reasonable. However, there appears to be a lack of planning and an unfocused approach when it comes to the seemingly random stream of refactoring pull requests that are isolating consensus state and code. These changes have a negative impact on downstream developers maintaining their own branches and cause frustration as complex code changes with longer development cycles than simple code movement patches keep breaking. The priority must be given to having a source code base that maximizes the collective developers' ability to maintain the core bitcoin full node P2P engine. To address these issues, the author recommends time-based bursts of code movement changes and a merge window approach like that used in the Linux kernel maintenance phases. They suggest merging changes during the first week of each month, followed by testing and bug fixing for the remaining days of the month before releasing at the end of the month. Pull requests that are not ready to merge within 7 days should be closed unless they are important bug fixes. The author also suggests closing the libconsensus project until a concrete goal is known, then generating and merging those changes in a time-based, paced manner.In conclusion, while modularity, refactoring, and cleaning up code generate happiness in many engineers, it can sometimes get in the way of more important work. Therefore, a disciplined development process is needed that prioritizes the collective developers' ability to maintain the core bitcoin full node P2P engine.
Updated on: 2023-06-10T22:28:38.266484+00:00