Clone this wiki locally
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
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
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
cpplint.py --filter=-build/include,-build/header_guard src/*.h src/*.cc
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. Which mod_pagespeed svn revision should be in the commit history. Someone inside Google should update trunk-tracking approximately weekly following these steps.