Process

Code should follow the Google style guide.

The code on the master branch should always build, pass tests, and be a jumping off point for anyone else working on ngx_pagespeed. It builds against a documented version of mod_pagespeed, and contains headers and binaries for that version.

All code changes need to be reviewed by someone else, ideally including someone at a different site. Work on a change in a branch labeled yourname-description (ex: jefftk-blocking-rewrite) and push often so that other people can see what you're doing. As master changes, rebase your feature branch off of master. This means you'll have to force-push (git push -f) but that's safe to do on your own branches. Just don't force-push on master.

When you have something ready to merge to master create a pull request and notify ngx-pagespeed-discuss so we can all look at it. After approval someone with commit access will squash the branch into a single commit and merge it into master.

Use cpplint:

cpplint.py  --filter=-build/include,-build/header_guard src/*.h src/*.cc

Before we can accept a patch from someone, Google needs to have an individual or corporate contributor license agreement (CLA) on file for them.

The trunk-tracking branch is a version of master that has fixes to work with the trunk version of mod_pagespeed. While trunk-tracking should be able to compile against a mod_pagespeed svn revision it won't necessarily compile against the current one because of api changes. When this happens pull requests are welcome. The mod_pagespeed binaries and headers in trunk-tracking make no attempt to be correct; with trunk-tracking you have to build mod_pagespeed from source. Changes from master are merged into trunk-tracking on a best-effort basis.