Published on: 2011-08-11T14:04:22+00:00
In an email exchange on August 10, 2011, Dr. Andy Parkins expressed his frustration with the rejection of new ideas from potential Bitcoin developers. He suggests a more distributed method for contributions and shares a list of ideas that were shot down by main developers. The conversation highlights the importance of flexibility while maintaining structure.The discussion between Andy Parkins and Jeff Garzik focuses on the development of Bitcoin. Andy argues for more freedom for developers to work on what they choose, while Jeff suggests a decentralized approach similar to Linux-next. The conversation emphasizes community involvement while maintaining code quality.The conversation also discusses the management of the development process for new releases of the Linux kernel. It is suggested to have an experimental branch for testing features that may not make it into stable releases. The idea of applying this approach to Bitcoin development is also discussed.Gavin Andresen and other Bitcoin developers discuss the reluctance of new developers to join the project due to their suggestions being rejected. Gavin believes the project needs more testers and bug-fixers rather than new feature proposals. The conversation highlights the importance of mentoring new developers and creating a development branch for showcasing work.John Smith suggests splitting the software into two versions: one with small changes and bug fixes, and another with major changes and refactorings. The idea of an experimental branch for untested features is also proposed. The conversation highlights the need for stability in main releases while allowing for testing and development of new features.Gavin Andresen opposes splitting off the "send commands to a running bitcoin" feature, citing compatibility concerns. However, he acknowledges the experimental phase of the project. The conversation also discusses the possibility of switching to two branches for bug fixes and development.The discussion continues on splitting Bitcoin into separate executables for UI and RPC. There are differing opinions on the benefits of a headless daemon and concerns about user usage patterns. The conversation also touches on the choice of build tools for different operating systems.Matt Corallo and John Smith discuss the idea of splitting the mainline client into separate executables. There is disagreement on the number of executables, but agreement on splitting off bitcoincl. Matt suggests pull-requesting bitcoin-qt and discusses the build process for Windows and OSX.Matt Corallo and Jeff Garzik debate the advantages and disadvantages of separating the Bitcoin daemon from the UI executable. They discuss the potential complexity for users and the flexibility it would provide for remote control of the daemon.John Smith's proposal to separate the mainline client into three executables is met with disagreement due to potential confusion for users. Matt agrees with splitting the source into separate components but opposes more executables. He suggests a pull-request if the goal is to distribute bitcoin-qt built off of bitcoind.In the current mainline client, there is a proposal to split functions into three executables: bitcoind, bitcoin(-qt), and bitcoincl. This would simplify main functions and prevent the UI from doubling as a daemon. The separation would also prevent accidental launching of the daemon/UI locally.
Updated on: 2023-08-01T02:15:10.334826+00:00