Author: Eric Lombrozo 2015-09-15 16:00:11
Published on: 2015-09-15T16:00:11+00:00
The context discusses the importance of well-coordinated refactoring efforts in Bitcoin Core. 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. However, continual refactoring can put pull requests in "rebase hell" and increase the risk of errors slipping through peer review, especially with consensus critical code.To address these issues, 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. Code moves and code style can be quickly reviewed and merged, while the third kind requires deeper analysis to ensure that the behavior remains unchanged.The author recommends having a "refactoring fortnight" where they do the bulk of code move-only refactoring plus code style where necessary. This would help everyone get an idea of the overall new structure and make it easier to find things in the future. Refactoring should be merged quickly, but only on a schedule so it doesn't cause major disruption to others. To achieve this, the author recommends an IRC meeting to agree on the initial moves, then someone who has the stomach for it can get on and do it - during that time, nothing else should be merged.Moreover, the author highlights the negative impact of complex code changes with longer development cycles than simple code movement patches keep breaking. It causes frustration and keeps breaking reasonable work languishing in constant-rebase hell, which incentivizes against keeping up with the latest tree. To address this issue, the author recommends time-based bursts of code movement changes. Finally, the author recommends having a source code base that maximizes the collective developers' ability to maintain The Router, the core bitcoin full node P2P engine. The email also discusses the nature of time-based development iteration and how releases can vary in terms of major features. The author expresses a desire to close GitHub pull requests that are not ready to merge within a week, with exceptions for important bug fixes. The author suggests a more disciplined development process, including only opening pull requests for bug fixes or when the merge window is open and the change is ready to be merged. Developers should CC the bitcoin-dev list to discuss Bitcoin Core-bound projects, maintain and publish projects via their own git trees, and pull requests should be closed if unmerged after 7 days. Refactoring and cleaning up code generates happiness in engineers but can sometimes get in the way of more important work.
Updated on: 2023-06-10T22:30:56.070671+00:00