Developer resources

• Things we could do after Varnish 2.0 is released
• Developer guidelines
• Using Subversion and SVK
• Packaging guidelines
• Release engineering procedures

• Notes from the architect
  • Introduction and Philosophy
  • Time and time-steps
  • How to implement Vary: efficiently
  • Purging when space is low
  • Random Notes
  • Prefetching
  • Backends and their policies
  • Degraded mode
  • Backend Polling
  • Inline C-code

• List of HTTP features (cribbed from Squid)

• Varnish project ideas

• Varnish test framework

Developer Rules

Social rules

Be sensible.

If in doubt, think.

If still in doubt, ask.

Admit your mistakes, it's faster that way.

Thou SHALL not paint bikesheds

Technical rules

Our coding style guideline is FreeBSD's style(9)

See autoconf.des script for developer options to the toolchain.

Use -Werror, there are no harmless warnings, only source code that does not express intent well enough.

Our reference platforms are Ubuntu and FreeBSD.

Asserts have negative cost, they save developer time next time around.

Our license is BSD 2-clause or looser, no GPL or LGPL.

Imported X11 project rules

It is as important to decide what a system is not as to decide what it is.

Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.

The only thing worse than generalizing from one example is generalizing from no examples at all.

If a problem is not completely understood, it is probably best to provide no solution at all.

If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution.

Isolate complexity as much as possible.

Provide mechanism, rather than policy.

Unwritten rules