New guidelines for maintenance branches

[Lasse Karstensen]

Hi all.

I'm easing up the policy on how and who can commit to the
maintenance branches of Varnish Cache. Typically 4.0 and 4.1.

The policy is defined by this wiki node:

    https://www.varnish-cache.org/trac/wiki/Maintenance_branch_guidelines

Contents copied from the wiki for your review:

"""
* The maintenance branches shall represent stable and consistent solutions
  for users. Users requiring the latest functionality have other options.

* The branches should always be possible to build.

* Pushed commits shall stand on their own. Documentation, test cases and any build
  system changes shall accompany the functional change.

* Functionality shall not be removed in minor releases.

* Functionality shall always be commited in master before any porting
  to maintenance branches.

* Changes requiring sign-off on email from the release manager:
  - New features or additions ported in from master.
  - Changes to global header files (cache.h in particular).
  - Anything involving VRT ABI version.
  - Output changes where it is reasonable to think users may parse it programmatically.

* Commits on the following can be commited by everyone freely:
  - Documentation changes.
  - Test case stabilization.

Commit rights will be given to active project members that request it. The
release manager decides exceptions, and may update this procedure as required.

If you are unsure, ask.
"""

-- 
Lasse Karstensen
(Release manager hat on.)