Re: [Bitcoin-development] Open development processes and reddit charms
I don't care which tabbing style or column width you pick, but **pick one**, and enforce it across the entire codebase. See https://github.com/bitcoin/bitcoin/pull/5387 Wladimir -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Open development processes and reddit charms
I'll pick up where you left off, Jeff. The thought process behind the Bitcoin Core threading model, platform support, libification, dependency management, core data structures, DoS mitigation, script evolution, scalability roadmap... just to scratch the surface, is likely never going to be apparent entirely from the source code itself, and will not, in its current form, be easily understood before digesting repository docs, repo issues, pull requests, IRC logs, mailing list archives (open and closed), forum posts, wiki articles, historical repositories, the foundation's technical blog, whitepapers, to name a few. I'd rather not guess how many have got a grip on it. If any, across the entire spectrum. It may be the bottleneck to address. I encourage everyone to take a look at the C# Language Design Notes* on codeplex. We'll know we've met the challenge when folks are no longer digging up gmaxwell's IRC comments to understand the rationale on nScriptCheckThreads, nor having to refer to sipa's stackexchange to figure out chainstate blockindex key/value pairs. * https://roslyn.codeplex.com/wikipage?title=CSharp%20Language%20Design%20NotesreferringTitle=Documentation On Tue, Dec 16, 2014 at 5:59 PM, Jeff Garzik jgar...@bitpay.com wrote: It can be useful to review open source development processes from time to time. This reddit thread[1] serves use both as a case study, and also a moment of OSS process introduction for newbies. [1] http://www.reddit.com/r/Bitcoin/comments/2pd0zy/peter_todd_is_saying_shoddy_development_on_v010/ *Dirty Laundry* When building businesses or commercial software projects, outsiders typically hear little about the internals of project development. The public only hears what the companies release, which is prepped and polished. Internal disagreements, schedule slips, engineer fistfights are all unseen. Open source development is the opposite. The goal is radical transparency. Inevitably there is private chatter (0day bugs etc.), but the default is openness. This means that is it normal practice to air dirty laundry in public. Engineers will disagree, sometimes quietly, sometimes loudly, sometimes rudely and with ad hominem attacks. On the Internet, there is a pile-on effect, where informed and uninformed supporters add their 0.02 BTC. Competing interests cloud the issues further. Engineers are typically employed by an organization, as a technology matures. Those organizations have different strategies and motivations. These organizations will sponsor work they find beneficial. Sometimes those orgs are non-profit foundations, sometimes for-profit corporations. Sometimes that work is maintenance (keep it running), sometimes that work is developing new, competitive features that company feels will give it a better market position. In a transparent development environment, all parties are hyperaware of these competing interests. Internet natterers painstakingly document and repeat every conspiracy theory about Bitcoin Foundation, Blockstream, BitPay, various altcoin developers, and more as a result of these competing interests. Bitcoin and altcoin development adds an interesting new dimension. Sometimes engineers have a more direct conflict of interest, in that the technology they are developing is also potentially their road to instant $millions. Investors, amateur and professional, have direct stakes in a certain coin or coin technology. Engineers also have an emotional stake in technology they design and nurture. This results in incentives where supporters of a non-bitcoin technology work very hard to thump bitcoin. And vice versa. Even inside bitcoin, you see tree chains vs. side chains threads of a similar stripe. This can lead to a very skewed debate. That should not distract from the engineering discussion. Starting from first principles, Assume Good Faith[2]. Most engineers in open source tend to mean what they say. Typically they speak for themselves first, and their employers value that engineer's freedom of opinion. Pay attention to the engineers actually working on the technology, and less attention to the noise bubbling around the Internet like the kindergarten game of grapevine. [2] http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith Being open and transparent means engineering disagreements happen in public. This is normal. Open source engineers live an aquarium life[3]. [3] https://www.youtube.com/watch?v=QKe-aO44R7k *What the fork?* In this case, a tweet suggests consensus bug risks, which reddit account treeorsidechains hyperbolizes into a dramatic headline[1]. However, the headline would seem to be the opposite of the truth. Several changes were merged during 0.10 development which move snippets of source code into new files and new sub-directories. The general direction of this work is creating a libconsensus library that carefully encapsulates consensus code in
Re: [Bitcoin-development] Open development processes and reddit charms
Thank you Jeff. Having looked at a lot of linux code, and now a lot of bitcoin code, the biggest long-term systemic risk I see is that Bitcoin has is the lack of code janitors. The problem is that janitoring was *disruptive* for non-x86 linux architectures when it first got going, and it's going to be very disruptive for bitcoin as well, but it **needs** to happen. The code is too complex and hard to follow as it is now. (now, I could just be speaking because I haven't paid the social debt of looking at the latest bitcoin code, including libconsensus), but there really needs to be a focus on readability, maintainability, and (as much as I hate to say it) a rather hard-line policy on coding standards. I don't care which tabbing style or column width you pick, but **pick one**, and enforce it across the entire codebase. Maybe this should be bitcoin-stable, and bitcoin-devel, with a 6-9 month social expectation of minimal cosmetic changes in -stable, with a 1 month 'merge window' where -devel turns into -stable. On Tue, Dec 16, 2014 at 12:59:06PM -0500, Jeff Garzik wrote: It can be useful to review open source development processes from time to time. This reddit thread[1] serves use both as a case study, and also a moment of OSS process introduction for newbies. [1] http://www.reddit.com/r/Bitcoin/comments/2pd0zy/peter_todd_is_saying_shoddy_development_on_v010/ *Dirty Laundry* When building businesses or commercial software projects, outsiders typically hear little about the internals of project development. The public only hears what the companies release, which is prepped and polished. Internal disagreements, schedule slips, engineer fistfights are all unseen. Open source development is the opposite. The goal is radical transparency. Inevitably there is private chatter (0day bugs etc.), but the default is openness. This means that is it normal practice to air dirty laundry in public. Engineers will disagree, sometimes quietly, sometimes loudly, sometimes rudely and with ad hominem attacks. On the Internet, there is a pile-on effect, where informed and uninformed supporters add their 0.02 BTC. Competing interests cloud the issues further. Engineers are typically employed by an organization, as a technology matures. Those organizations have different strategies and motivations. These organizations will sponsor work they find beneficial. Sometimes those orgs are non-profit foundations, sometimes for-profit corporations. Sometimes that work is maintenance (keep it running), sometimes that work is developing new, competitive features that company feels will give it a better market position. In a transparent development environment, all parties are hyperaware of these competing interests. Internet natterers painstakingly document and repeat every conspiracy theory about Bitcoin Foundation, Blockstream, BitPay, various altcoin developers, and more as a result of these competing interests. Bitcoin and altcoin development adds an interesting new dimension. Sometimes engineers have a more direct conflict of interest, in that the technology they are developing is also potentially their road to instant $millions. Investors, amateur and professional, have direct stakes in a certain coin or coin technology. Engineers also have an emotional stake in technology they design and nurture. This results in incentives where supporters of a non-bitcoin technology work very hard to thump bitcoin. And vice versa. Even inside bitcoin, you see tree chains vs. side chains threads of a similar stripe. This can lead to a very skewed debate. That should not distract from the engineering discussion. Starting from first principles, Assume Good Faith[2]. Most engineers in open source tend to mean what they say. Typically they speak for themselves first, and their employers value that engineer's freedom of opinion. Pay attention to the engineers actually working on the technology, and less attention to the noise bubbling around the Internet like the kindergarten game of grapevine. [2] http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith Being open and transparent means engineering disagreements happen in public. This is normal. Open source engineers live an aquarium life[3]. [3] https://www.youtube.com/watch?v=QKe-aO44R7k *What the fork?* In this case, a tweet suggests consensus bug risks, which reddit account treeorsidechains hyperbolizes into a dramatic headline[1]. However, the headline would seem to be the opposite of the truth. Several changes were merged during 0.10 development which move snippets of source code into new files and new sub-directories. The general direction of this work is creating a libconsensus library that carefully encapsulates consensus code in a manner usable by external projects. This is a good thing. The development was performed quite responsible: Multiple developers would verify
