.gitignore

@@ -9,12 +9,33 @@
 core
 vgcore.*
 .buildstamp
-
-/libuv.so
+.dirstamp
+.deps/
+/.libs/
+/aclocal.m4
+/ar-lib
+/autom4te.cache/
+/compile
+/config.guess
+/config.log
+/config.status
+/config.sub
+/configure
+/depcomp
+/install-sh
+/libtool
+/libuv.a
 /libuv.dylib
+/libuv.pc
+/libuv.so
+/ltmain.sh
+/missing
+/test-driver
+Makefile
+Makefile.in
 
 # Generated by dtrace(1) when doing an in-tree build.
-/src/unix/uv-dtrace.h
+/include/uv-dtrace.h
 
 /out/
 /build/gyp

.mailmap

@@ -6,6 +6,8 @@ Brian White <mscdex@mscdex.net>
 Brian White <mscdex@mscdex.net> <mscdex@gmail.com>
 Frank Denis <github@pureftpd.org>
 Isaac Z. Schlueter <i@izs.me>
+Keno Fischer <kenof@stanford.edu> <kfischer+github@college.harvard.edu>
+Keno Fischer <kenof@stanford.edu> <kfischer@college.harvard.edu>
 Robert Mustacchi <rm@joyent.com> <rm@fingolfin.org>
 Ryan Dahl <ryan@joyent.com> <ry@tinyclouds.org>
 Ryan Emery <seebees@gmail.com>

AUTHORS

@@ -79,11 +79,23 @@ Tim Bradshaw <tfb@cley.com>
 Timothy J. Fontaine <tjfontaine@gmail.com>
 Marc Schlaich <marc.schlaich@googlemail.com>
 Brian Mazza <louseman@gmail.com>
+Elliot Saba <staticfloat@gmail.com>
+Ben Kelly <ben@wanderview.com>
+Kristian Evensen <kristian.evensen@gmail.com>
 Nils Maier <maierman@web.de>
 Nicholas Vavilov <vvnicholas@gmail.com>
 Miroslav Bajtoš <miro.bajtos@gmail.com>
-Elliot Saba <staticfloat@gmail.com>
+Sean Silva <chisophugis@gmail.com>
 Wynn Wilkes <wynnw@movenetworks.com>
+Linus Mårtensson <linus.martensson@sonymobile.com>
 Andrei Sedoi <bsnote@gmail.com>
+Navaneeth Kedaram Nambiathan <navaneethkn@gmail.com>
+Alex Crichton <alex@alexcrichton.com>
+Brent Cook <brent@boundary.com>
+Brian Kaisner <bkize1@gmail.com>
+Luca Bruno <lucab@debian.org>
+Reini Urban <rurban@cpanel.net>
+Maks Naumov <maksqwe1@ukr.net>
+Sean Farrell <sean.farrell@rioki.org>
 Chris Bank <cbank@adobe.com>
 Geert Jansen <geertj@gmail.com>

CONTRIBUTING.md

@@ -0,0 +1,174 @@
+# CONTRIBUTING
+
+The libuv project welcomes new contributors. This document will guide you
+through the process.
+
+
+### FORK
+
+Fork the project [on GitHub](https://github.com/joyent/libuv) and check out
+your copy.
+
+```
+$ git clone git@github.com:username/libuv.git
+$ cd libuv
+$ git remote add upstream git://github.com/joyent/libuv.git
+```
+
+Now decide if you want your feature or bug fix to go into the master branch
+or the stable branch.  As a rule of thumb, bug fixes go into the stable branch
+while new features go into the master branch.
+
+The stable branch is effectively frozen; patches that change the libuv
+API/ABI or affect the run-time behavior of applications get rejected.
+
+In case of doubt, open an issue in the [issue tracker][], post your question
+to the [libuv mailing list], or contact one of project maintainers
+(@bnoordhuis, @piscisaureus, @indutny or @saghul) on [IRC][].
+
+Especially do so if you plan to work on something big.  Nothing is more
+frustrating than seeing your hard work go to waste because your vision
+does not align with that of a project maintainers.
+
+
+### BRANCH
+
+Okay, so you have decided on the proper branch.  Create a feature branch
+and start hacking:
+
+```
+$ git checkout -b my-feature-branch -t origin/v0.10
+```
+
+(Where v0.10 is the latest stable branch as of this writing.)
+
+### CODE
+
+Please adhere to libuv's code style. In general it follows the conventions from
+the [Google C/C++ style guide]. Some of they key points are reiterated below.
+
+* Code that is specific to unix-y platforms should be places in `src/unix`, and
+  declarations go into `src/uv-unix.h`.
+
+* Source code that is windows-specific goes into `src/win`, and related
+  publicly exported types, functions and macro declarations should generally
+  be declared in `include/uv-win.h`.
+
+* Names should be descriptive and concise.
+
+* All the symbols and types that libuv makes available publicly should be
+  prefixed with `uv_` (or `UV_` in case of macros).
+
+* Internal, non-static functions should be prefixed with `uv__`.
+
+* Use two spaces and no tabs.
+
+* Lines should be wrapped at 80 characters.
+
+* Ensure that lines have no trailing whitespace, and use unix-style (LF) line
+  endings.
+
+* Use C89-compliant syntax. In other words, variables can only be declared at
+  the top of a scope (function, if/for/while-block).
+
+* When writing comments, use properly constructed sentences, including
+  punctuation.
+
+* When documenting APIs and/or source code, don't make assumptions or make
+  implications about race, gender, religion, political orientation or anything
+  else that isn't relevant to the project.
+
+* Remember that source code usually gets written once and read often: ensure
+  the reader doesn't have to make guesses. Make sure that the purpose and inner
+  logic are either obvious to a reasonably skilled professional, or add a
+  comment that explains it.
+
+
+### COMMIT
+
+Make sure git knows your name and email address:
+
+```
+$ git config --global user.name "J. Random User"
+$ git config --global user.email "j.random.user@example.com"
+```
+
+Writing good commit logs is important.  A commit log should describe what
+changed and why.  Follow these guidelines when writing one:
+
+1. The first line should be 50 characters or less and contain a short
+   description of the change prefixed with the name of the changed
+   subsystem (e.g. "net: add localAddress and localPort to Socket").
+2. Keep the second line blank.
+3. Wrap all other lines at 72 columns.
+
+A good commit log looks like this:
+
+```
+subsystem: explaining the commit in one line
+
+Body of commit message is a few lines of text, explaining things
+in more detail, possibly giving some background about the issue
+being fixed, etc etc.
+
+The body of the commit message can be several paragraphs, and
+please do proper word-wrap and keep columns shorter than about
+72 characters or so. That way `git log` will show things
+nicely even when it is indented.
+```
+
+The header line should be meaningful; it is what other people see when they
+run `git shortlog` or `git log --oneline`.
+
+Check the output of `git log --oneline files_that_you_changed` to find out
+what subsystem (or subsystems) your changes touch.
+
+
+### REBASE
+
+Use `git rebase` (not `git merge`) to sync your work from time to time.
+
+```
+$ git fetch upstream
+$ git rebase upstream/v0.10  # or upstream/master
+```
+
+
+### TEST
+
+Bug fixes and features should come with tests.  Add your tests in the
+`test/` directory. Tests also need to be registered in `test/test-list.h`.
+Look at other tests to see how they should be structured (license boilerplate,
+the way entry points are declared, etc.).
+
+```
+$ make test
+```
+
+Make sure that there are no test regressions.
+
+### PUSH
+
+```
+$ git push origin my-feature-branch
+```
+
+Go to https://github.com/username/libuv and select your feature branch.  Click
+the 'Pull Request' button and fill out the form.
+
+Pull requests are usually reviewed within a few days.  If there are comments
+to address, apply your changes in a separate commit and push that to your
+feature branch.  Post a comment in the pull request afterwards; GitHub does
+not send out notifications when you add commits.
+
+
+### CONTRIBUTOR LICENSE AGREEMENT
+
+Please visit http://libuvjs.org/cla.html and sign the Contributor License
+Agreement.  You only need to do that once.
+
+
+[issue tracker]: https://github.com/joyent/libuv/issues
+[libuv mailing list]: http://groups.google.com/group/libuv
+[IRC]: http://webchat.freelibuv.net/?channels=libuv
+[Google C/C++ style guide]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml