Skip to content


Jeff Kaufman edited this page · 8 revisions

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:  --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. Which mod_pagespeed svn revision should be in the commit history. Someone inside Google should update trunk-tracking approximately weekly following these steps.

Something went wrong with that request. Please try again.