Thanks to everyone who has responded to my points. It's really encouraging to hear everyone's supporting thoughts.
On 12 April 2012 00:22, Paul Davis <[email protected]> wrote: > On Tue, Apr 10, 2012 at 8:46 PM, Tim McNamara > <[email protected]> wrote: >> After chatting with Noah S on Twitter, I offered to jot up some >> thoughts on things that my reduce or eliminate perceived barriers to >> entry to work on CouchDB. >> >> Here are a few things that I've been able to think of. In the course >> of researching this mail though, I've actually answered many of my own >> questions. >> >> "serious business" >> A database seems like the kind of project that only extremely talented >> people would touch. People depend on the code working. Getting started >> would require quite a bit of confidence. Am I good enough? >> > > @antirez of Redis fame did a really great post on data durability a > couple weeks ago. If you read and understand that you're briefed > enough to start diving into the code. Beyond those basics the advanced > details are more about learning the details of how certain types of > hardware reacts to those POSIX API's. Ie, stuff that @antirez alludes > to but doesn't cover (non-volatile write caches being a fun one). > > http://antirez.com/post/redis-persistence-demystified.html > > >> >> "Erlang, wtf" >> This is a barrier that I've been facing for a while. I'm actually in >> the process of learning Erlang, trying to expand my horizons from >> Python. Still, a new language makes it harder to have the required >> confidence. >> > > Heh, I still say "Erlang, wtf?" after using it for a few years. But I > think that's true of any language I've used for any extended period of > time. As much as I love Python it's still got its warts (outer > variables not captured by closures?). > > In the end I would wager that a big part of the Erlang stumbling block > is that it's also functional and that is a stumbling block for some. > When I started with it I was like "oh, its one of those academic > things the CS people dreamed up," and didn't get into it right away. > But once you get into it you realize its not as hard as you made it > out to be. > >> >> "I still don't understand rereduce" >> I'm personally not 100% clear on how queries work. This is even after >> using the db for a while. I don't want to look like a stupid idiot in >> front of great developers. Therefore, there's a high risk of offering >> suggestions and getting told to "RTFM" >> > > For this I would say come ask in IRC or on the dev@ list. There are > also some older resources that still do a decent job of describing the > internals. But I would say no one expects any new comer to jump in and > tackle some of the core modules without first learning how they're > used in other places in the code. > > http://horicky.blogspot.com/2008/10/couchdb-implementation.html > >> >> "Where are the easy bugs?" >> [solved] >> >> >> "wow, big code base" >> Is there any documentation on how to project is laid out? Stepping >> into a new project is always a little daunting. >> > > You're joking, right? :D CouchDB is something like 15K lines (although > in a weird language and not as clean as it could be) but compared to > other similar databases that's absolutely tiny. > > That said, there's not much excuse for us to not have documentation on > code layout and the internal and external APIs and so forth. Hopefully > we'll be doing some work in the next few months to try and address > this issue. > >> >> "Apache project?" >> As someone outside of the ASF, I don't really know what contributing >> on an Apache project means. > > Don't worry about this. As you start contributing its the same as any > other open source project since the beginning of open source. Look at > the code, make a change, submit it back. > > Other than that, I would say if you're interested in contributing to > pick one section of the code base and start reading and trying to > understand. Do some hacking and see if you can break it or change its > behavior in fun ways. My personal quest into the internals started at > the HTTP layer, worked into the view engine, and then finally to the > actual core. For me that was just what I found interesting at the > time. I could see another approach to start at the level of couch_file > and work outwards if that seems more approchable. > > HTH and always feel free to ask questions, > Paul Davis
