Published on: 2015-09-29T13:04:09+00:00
There has been a discussion among Bitcoin developers about the best approach to large-scale refactoring in Bitcoin development. The consensus is that such projects should occur over a short period of time and have a written plan beforehand. Concerns were raised about the seemingly random nature of libconsensus refactoring pull requests (PRs) and the impact they can have on downstream developers. It was suggested that developers require more links or "hooks" to see the missing aspects in the development process.Jorge Timón, the developer working on libconsensus, responded by stating that he had communicated his plans for libconsensus multiple times but acknowledged that there was still work to be done to help people understand his proposals and structure his pull requests more effectively. He consolidated three small consensus-related PRs into one with the hope that it would be merged relatively fast.Gavin Andresen proposed a plan to separate consensus code into libconsensus, which is important for less risky and wider contributions. The library will provide full consensus validation for Script, Block Headers, Transactions, and Blocks. Jorge Timón responded to concerns about the seemingly random stream of refactors for libconsensus without any apparent plan or end, stating that just because someone doesn't understand the changes proposed doesn't mean they are random. He described his plan for libconsensus and tried creating big pull requests for people to see the big picture, but nobody wanted to read it. Instead, he had smaller one-little-step PRs that were part of a longer branch.The need for more links or hooks for developers to see the plan, order, and sense in the endless stream of libconsensus refactoring PRs was discussed. Jeff Garzik pointed out that complex code changes with longer development cycles than simple code movement patches keep breaking. He suggested making a plan and not seeing a five-year stream of random consensus code movement patches causing lots of downstream developer headaches. Developers were encouraged to imagine several different ways people might try to find this description in the future and make them work.In a discussion on the Bitcoin-dev mailing list, it was suggested that companies can maintain forks of Bitcoin Core unnecessarily when a different architecture could do what they need without including new logic in the codebase itself. The goal is to have a more modular, reusable, and maintainable codebase where new functionality can be plugged in easily. However, bitcoind's design is still too monolithic and adding a new feature requires the code to be touched all over the place, potentially breaking base node functionality. Therefore, if possible, functionality should be built without changing bitcoind's code at all. An example of this is Monero's 'simplewallet', which communicates with the node software and remembers where it was in the chain. An index could be implemented entirely externally in a similar way while fully handling reorgs.Jeff Garzik highlighted the negative impact of refactors, stating that branches of the source tree are being maintained by various developers. He emphasized the need to understand why these branches are being maintained and what features they have that Bitcoin Core doesn't. He suggested that if refactoring were accelerated and scheduled to be performed in a one-week sprint, the long-term developer impact would be much less. This approach can be compared to "ripping the band-aid off quickly rather than slowly".The importance of well-coordinated refactoring efforts in Bitcoin Core was discussed. While refactoring can be disruptive in the short term, it can make it easier for downstream developers to add and merge changes in the longer term. To address issues with refactoring, the author suggests scheduling move-only changes and documenting them in a way that helps other developers rebase properly. The author also proposes a plan for three major kinds of refactoring: code moves, code style, and structural optimization and consolidation. The author recommends having a "refactoring fortnight" where the bulk of code move-only refactoring plus code style changes can be done. Refactoring should be merged quickly, but only on a schedule so it doesn't cause major disruption to others. The author also emphasizes the negative impact of complex code changes with longer development cycles than simple code movement patches.Overall, the discussion highlights the need for better planning and coordination in large-scale refactoring efforts in Bitcoin development. It emphasizes the importance of clear communication, proper documentation, and scheduling of refactoring activities to minimize disruptions and ensure smooth integration of changes.Bitcoin Core, the codebase for the Bitcoin network, requires extensive modularization to improve its structure. However, this process needs careful planning and consideration for downstream projects and contributors. Continual refactoring can cause issues, such as pull requests getting stuck in "rebase hell" and creating stress for contributors. To mitigate these problems, refactoring should be merged quickly but on a schedule that minimizes disruption. There are three types of refactoring: code moves, code style changes, and structural optimization and consolidation.
Updated on: 2023-08-01T16:08:08.707004+00:00