Development#

Obtaining Sources#

You can clone Angie OSS source code from our public repositories: Mercurial, Git.

Coding Style#

Your changes should be consistent with the rest of Angie’s code; the nginx coding guidelines are a good starting point. However, mind there are notable differences, especially in the API code.

Tip

If in doubt, examine the nearby code to follow its lead, or simply grep the codebase for inspiration.

Commit Messages#

Start with a one-line summary of what was done. It may have a prefix that the commit log uses for the affected code portion. The summary can be up to 67 characters long and may be followed by a blank line and more details.

A good message tells what caused the change, what was done about it, and what the situation is now:

API: bad things removed, good things added.

As explained elsewhere[1], the original API was bad because stuff;
this change was introduced to improve that aspect locally.

Levels of goodness have been implemented to mitigate the badness;
this is now the preferred way to work.  Also, the badness is gone.

[1] https://example.com

Details that may otherwise go unnoticed:

  • Summary ends with a period and uses sentence case

  • Summary prefix is followed by lowercase

  • Double whitespace separates sentences within a single line

Final Checks#

  • Do your best to verify that the changes work on all target platforms.

  • For each platform, run the test suite to make sure there’s no regression:

    $ cd tests
    $ prove .
    

    See the tests/README file for details.

  • Make sure you’re comfortable with the legal terms.

Submitting Contributions#

Currently, we can’t accept direct commits to our repos, so create a PR on our GitHub mirror instead.

With questions and suggestions, please contact the developers via GitHub Issues.