On Tue, Apr 10, 2012 at 8:46 PM, Tim McNamara <paperl...@timmcnamara.co.nz> 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
