<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>[15514] CalendarServer/trunk</title>
</head>
<body>
<style type="text/css"><!--
#msg dl.meta { border: 1px #006 solid; background: #369; padding: 6px; color: #fff; }
#msg dl.meta dt { float: left; width: 6em; font-weight: bold; }
#msg dt:after { content:':';}
#msg dl, #msg dt, #msg ul, #msg li, #header, #footer, #logmsg { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; }
#msg dl a { font-weight: bold}
#msg dl a:link { color:#fc3; }
#msg dl a:active { color:#ff0; }
#msg dl a:visited { color:#cc6; }
h3 { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; font-weight: bold; }
#msg pre { overflow: auto; background: #ffc; border: 1px #fa0 solid; padding: 6px; }
#logmsg { background: #ffc; border: 1px #fa0 solid; padding: 1em 1em 0 1em; }
#logmsg p, #logmsg pre, #logmsg blockquote { margin: 0 0 1em 0; }
#logmsg p, #logmsg li, #logmsg dt, #logmsg dd { line-height: 14pt; }
#logmsg h1, #logmsg h2, #logmsg h3, #logmsg h4, #logmsg h5, #logmsg h6 { margin: .5em 0; }
#logmsg h1:first-child, #logmsg h2:first-child, #logmsg h3:first-child, #logmsg h4:first-child, #logmsg h5:first-child, #logmsg h6:first-child { margin-top: 0; }
#logmsg ul, #logmsg ol { padding: 0; list-style-position: inside; margin: 0 0 0 1em; }
#logmsg ul { text-indent: -1em; padding-left: 1em; }#logmsg ol { text-indent: -1.5em; padding-left: 1.5em; }
#logmsg > ul, #logmsg > ol { margin: 0 0 1em 0; }
#logmsg pre { background: #eee; padding: 1em; }
#logmsg blockquote { border: 1px solid #fa0; border-left-width: 10px; padding: 1em 1em 0 1em; background: white;}
#logmsg dl { margin: 0; }
#logmsg dt { font-weight: bold; }
#logmsg dd { margin: 0; padding: 0 0 0.5em 0; }
#logmsg dd:before { content:'\00bb';}
#logmsg table { border-spacing: 0px; border-collapse: collapse; border-top: 4px solid #fa0; border-bottom: 1px solid #fa0; background: #fff; }
#logmsg table th { text-align: left; font-weight: normal; padding: 0.2em 0.5em; border-top: 1px dotted #fa0; }
#logmsg table td { text-align: right; border-top: 1px dotted #fa0; padding: 0.2em 0.5em; }
#logmsg table thead th { text-align: center; border-bottom: 1px solid #fa0; }
#logmsg table th.Corner { text-align: left; }
#logmsg hr { border: none 0; border-top: 2px dashed #fa0; height: 1px; }
#header, #footer { color: #fff; background: #636; border: 1px #300 solid; padding: 6px; }
#patch { width: 100%; }
#patch h4 {font-family: verdana,arial,helvetica,sans-serif;font-size:10pt;padding:8px;background:#369;color:#fff;margin:0;}
#patch .propset h4, #patch .binary h4 {margin:0;}
#patch pre {padding:0;line-height:1.2em;margin:0;}
#patch .diff {width:100%;background:#eee;padding: 0 0 10px 0;overflow:auto;}
#patch .propset .diff, #patch .binary .diff {padding:10px 0;}
#patch span {display:block;padding:0 10px;}
#patch .modfile, #patch .addfile, #patch .delfile, #patch .propset, #patch .binary, #patch .copfile {border:1px solid #ccc;margin:10px 0;}
#patch ins {background:#dfd;text-decoration:none;display:block;padding:0 10px;}
#patch del {background:#fdd;text-decoration:none;display:block;padding:0 10px;}
#patch .lines, .info {color:#888;background:#fff;}
--></style>
<div id="msg">
<dl class="meta">
<dt>Revision</dt> <dd><a href="http://trac.calendarserver.org//changeset/15514">15514</a></dd>
<dt>Author</dt> <dd>sagen@apple.com</dd>
<dt>Date</dt> <dd>2016-04-18 09:10:04 -0700 (Mon, 18 Apr 2016)</dd>
</dl>
<h3>Log Message</h3>
<pre>Rename Contributing.rst back to HACKING.rst, with url tweaks.</pre>
<h3>Modified Paths</h3>
<ul>
<li><a href="#CalendarServertrunkHACKINGrst">CalendarServer/trunk/HACKING.rst</a></li>
</ul>
<h3>Removed Paths</h3>
<ul>
<li><a href="#CalendarServertrunkContributingrst">CalendarServer/trunk/Contributing.rst</a></li>
</ul>
</div>
<div id="patch">
<h3>Diff</h3>
<a id="CalendarServertrunkContributingrst"></a>
<div class="delfile"><h4>Deleted: CalendarServer/trunk/Contributing.rst (15513 => 15514)</h4>
<pre class="diff"><span>
<span class="info">--- CalendarServer/trunk/Contributing.rst        2016-04-18 15:20:08 UTC (rev 15513)
+++ CalendarServer/trunk/Contributing.rst        2016-04-18 16:10:04 UTC (rev 15514)
</span><span class="lines">@@ -1,422 +0,0 @@
</span><del>-Developer's Guide to Contributing to the Calendar Server
-========================================================
-
-If you are interested in contributing to the Calendar and Contacts
-Server project, please read this document.
-
-
-Participating in the Community
-==============================
-
-The Calendar and Contacts Server began in 1996 -- an open source
-project sponsored and hosted by Apple Inc. (http://www.apple.com/).
-The project is now hosted at GitHub, and although it lives within
-the "apple" namespace it's stil a true open-source project under
-an Apache license. Contributions from other developers are welcome,
-and, as with all open development projects, may lead to "commit
-access" and a voice in the future of the project.
-
-The community exists mainly through mailing lists and a GitHub
-repository. To participate, go to:
-
- http://trac.calendarserver.org/projects/calendarserver/wiki/MailLists
-
-and join the appropriate mailing lists. We also use IRC, as described
-here:
-
- http://trac.calendarserver.org/projects/calendarserver/wiki/IRC
-
-There are many ways to join the project. One may write code, test the
-software and file bugs, write documentation, etc.
-
-The issue tracking database is here:
-
- https://github.com/apple/ccs-calendarserver/issues
-
-To help manage the issues database, read over the issue summaries,
-looking and testing for issues that are either invalid, or are
-duplicates of other issues. Both kinds are very common, the first
-because bugs often get unknowingly fixed as side effects of other
-changes in the code, and the second because people sometimes file an
-issue without noticing that it has already been reported. If you are
-not sure about an issue, post a question to
-
- calendarserver-dev@lists.macosforge.org.
-
-Before filing bugs, please take a moment to perform a quick search to
-see if someone else has already filed your bug. In that case, add a
-comment to the existing bug if appropriate and monitor it, rather than
-filing a duplicate.
-
-
-Obtaining the Code
-==================
-
-The source code to the Calendar and Contacts Server is available via
-Git at this repository URL:
-
- https://github.com/apple/ccs-calendarserver.git
-
-
-Directory Layout
-================
-
-A rough guide to the source tree:
-
- * ``doc/`` - User and developer documentation, including relevant
- protocol specifications and extensions.
-
- * ``bin/`` - Executable programs.
-
- * ``conf/`` - Configuration files.
-
- * ``calendarserver/`` - Source code for the Calendar and Contacts
- Server
-
- * ``twistedcaldav/`` - Source code for CalDAV library
-
- * ``twisted/`` - Files required to set up the Calendar and Contacts
- Server as a Twisted service. Twisted (http://twistedmatrix.com/)
- is a networking framework upon which the Calendar and Contacts
- Server is built.
-
- * ``locales/`` - Localization files.
-
- * ``contrib/`` - Extra stuff that works with the Calendar and
- Contacts Server, or that helps integrate with other software
- (including operating systems), but that the Calendar and Contacts
- Server does not depend on.
-
- * ``support/`` - Support files of possible use to developers.
-
-
-Coding Standards
-================
-
-The vast majority of the Calendar and Contacts Server is written in
-the Python programming language. When writing Python code for the
-Calendar and Contacts Server, please observe the following
-conventions.
-
-Please note that all of our code at present does not follow these
-standards, but that does not mean that one shouldn't bother to do so.
-On the contrary, code changes that do nothing but reformat code to
-comply with these standards are welcome, and code changes that do not
-conform to these standards are discouraged.
-
-**We require Python 2.6 or higher.** It therefore is OK to write code
-that does not work with Python versions older than 2.6.
-
-Read PEP-8:
-
- http://www.python.org/dev/peps/pep-0008/
-
-For the most part, our code should follow PEP-8, with a few exceptions
-and a few additions. It is also useful to review the Twisted Coding
-Standard, from which we borrow some standards, though we don't
-strictly follow it:
-
- http://twistedmatrix.com/trac/browser/trunk/doc/development/policy/coding-standard.xhtml?format=raw
-
-Key items to follow, and specifics:
-
- * Indent level is 4 spaces.
-
- * Never indent code with tabs. Always use spaces.
-
-PEP-8 items we do not follow:
-
- * PEP-8 recommends using a backslash to break long lines up:
-
- ::
-
- if width == 0 and height == 0 and \
- color == 'red' and emphasis == 'strong' or \
- highlight > 100:
- raise ValueError("sorry, you lose")
-
- Don't do that, it's gross, and the indentation for the ``raise`` line
- gets confusing. Use parentheses:
-
- ::
-
- if (
- width == 0 and
- height == 0 and
- color == "red" and
- emphasis == "strong" or
- highlight > 100
- ):
- raise ValueError("sorry, you lose")
-
- Just don't do it the way PEP-8 suggests:
-
- ::
-
- if width == 0 and height == 0 and (color == 'red' or
- emphasis is None):
- raise ValueError("I don't think so")
-
- Because that's just silly.
-
-Additions:
-
- * Close parentheses and brackets such as ``()``, ``[]`` and ``{}`` at the
- same indent level as the line in which you opened it:
-
- ::
-
- launchAtTarget(
- target="David",
- object=PaperWad(
- message="Yo!",
- crumpleFactor=0.7,
- ),
- speed=0.4,
- )
-
- * Long lines are often due to long strings. Try to break strings up
- into multiple lines:
-
- ::
-
- processString(
- "This is a very long string with a lot of text. "
- "Fortunately, it is easy to break it up into parts "
- "like this."
- )
-
- Similarly, callables that take many arguments can be broken up into
- multiple lines, as in the ``launchAtTarget()`` example above.
-
- * Breaking generator expressions and list comprehensions into
- multiple lines can improve readability. For example:
-
- ::
-
- myStuff = (
- item.obtainUsefulValue()
- for item in someDataStore
- if item.owner() == me
- )
-
- * Import symbols (especially class names) from modules instead of
- importing modules and referencing the symbol via the module unless
- it doesn't make sense to do so. For example:
-
- ::
-
- from subprocess import Popen
-
- process = Popen(...)
-
- Instead of:
-
- ::
-
- import subprocess
-
- process = subprocess.Popen(...)
-
- This makes code shorter and makes it easier to replace one implementation
- with another.
-
- * All files should have an ``__all__`` specification. Put them at the
- top of the file, before imports (PEP-8 puts them at the top, but
- after the imports), so you can see what the public symbols are for
- a file right at the top.
-
- * It is more important that symbol names are meaningful than it is
- that they be concise. ``x`` is rarely an appropriate name for a
- variable. Avoid contractions: ``transmogrifierStatus`` is more useful
- to the reader than ``trmgStat``.
-
- * A deferred that will be immediately returned may be called ``d``:
-
- ::
-
- d = doThisAndThat()
- d.addCallback(onResult)
- d.addErrback(onError)
- return d
-
- * Do not use ``deferredGenerator``. Use ``inlineCallbacks`` instead.
-
- * That said, avoid using ``inlineCallbacks`` when chaining deferreds
- is straightforward, as they are more expensive. Use
- ``inlineCallbacks`` when necessary for keeping code maintainable,
- such as when creating serialized deferreds in a for loop.
-
- * ``_`` may be used to denote unused callback arguments:
-
- ::
-
- def onCompletion(_):
- # Don't care about result of doThisAndThat() in here;
- # we only care that it has completed.
- doNextThing()
-
- d = doThisAndThat()
- d.addCallback(onCompletion)
- return d
-
- * Do not prefix symbols with ``_`` unless they might otherwise be
- exposed as a public symbol: a private method name should begin with
- ``_``, but a locally scoped variable should not, as there is no
- danger of it being exposed. Locally scoped variables are already
- private.
-
- * Per twisted convention, use camel-case (``fuzzyWidget``,
- ``doThisAndThat()``) for symbol names instead of using underscores
- (``fuzzy_widget``, ``do_this_and_that()``).
-
- Use of underscores is reserved for implied dispatching and the like
- (eg. ``http_FOO()``). See the Twisted Coding Standard for details.
-
- * Do not use ``%``-formatting:
-
- ::
-
- error = "Unexpected value: %s" % (value,)
-
- Use PEP-3101 formatting instead:
-
- ::
-
- error = "Unexpected value: {value}".format(value=value)
-
- * If you must use ``%``-formatting for some reason, always use a tuple as
- the format argument, even when only one value is being provided:
-
- ::
-
- error = "Unexpected value: %s" % (value,)
-
- Never use the non-tuple form:
-
- ::
-
- error = "Unexpected value: %s" % value
-
- Which is allowed in Python, but results in a programming error if
- ``type(value) is tuple and len(value) != 1``.
-
- * Don't use a trailing ``,`` at the end of a tuple if it's on one line:
-
- ::
-
- numbers = (1,2,3,) # No
- numbers = (1,2,3) # Yes
-
- The trailing comma is desirable on multiple lines, though, as that makes
- re-ordering items easy, and avoids a diff on the last line when adding
- another:
-
- ::
-
- strings = (
- "This is a string.",
- "And so is this one.",
- "And here is yet another string.",
- )
-
- * Docstrings are important. All public symbols (anything declared in
- ``__all__``) must have a correct docstring. The script
- ``docs/Developer/gendocs`` will generate the API documentation using
- ``pydoctor``. See the ``pydoctor`` documentation for details on the
- formatting:
-
- http://codespeak.net/~mwh/pydoctor/
-
- Note: existing docstrings need a complete review.
-
- * Use PEP-257 as a guideline for docstrings.
-
- * Begin all multi-line docstrings with 3 double quotes and a
- newline:
-
- ::
-
- def doThisAndThat(...):
- """
- Do this, and that.
- ...
- """
-
-
-Best Practices
-==============
-
- * If a callable is going to return a Deferred some of the time, it
- should return a deferred all of the time. Return ``succeed(value)``
- instead of ``value`` if necessary. This avoids forcing the caller
- to check as to whether the value is a deferred or not (eg. by using
- ``maybeDeferred()``), which is both annoying to code and potentially
- expensive at runtime.
-
- * Be proactive about closing files and file-like objects.
-
- For a lot of Python software, letting Python close the stream for
- you works fine, but in a long-lived server that's processing many
- data streams at a time, it is important to close them as soon as
- possible.
-
- On some platforms (eg. Windows), deleting a file will fail if the
- file is still open. By leaving it up to Python to decide when to
- close a file, you may find yourself being unable to reliably delete
- it.
-
- The most reliable way to ensure that a stream is closed is to put
- the call to ``close()`` in a ``finally`` block:
-
- ::
-
- stream = file(somePath)
- try:
- ... do something with stream ...
- finally:
- stream.close()
-
-
-Testing
-=======
-
-Be sure that all of the units tests pass before you commit new code.
-Code that breaks units tests may be reverted without further
-discussion; it is up to the committer to fix the problem and try
-again.
-
-Note that repeatedly committing code that breaks units tests presents
-a possible time sink for other developers, and is not looked upon
-favorably.
-
-Units tests can be run rather easily by executing the ``./bin/test`` script
-at the top of the Calendar and Contacts Server source tree. By
-default, it will run all of the Calendar and Contacts Server tests
-followed by all of the Twisted tests. You can run specific tests by
-specifying them as arguments like this:
-
- ::
-
- ./bin/test twistedcaldav.static
-
-All non-trivial public callables must have unit tests. (Note we don't
-don't totally comply with this rule; that's a problem we'd like to
-fix.) All other callables should have unit tests.
-
-Units tests are written using the ``twisted.trial`` framework. Test
-module names should start with ``test_``. Twisted has some tips on
-writing tests here:
-
- http://twistedmatrix.com/projects/core/documentation/howto/testing.html
-
- http://twistedmatrix.com/trac/browser/trunk/doc/development/policy/test-standard.xhtml?format=raw
-
-We also use CalDAVTester (which is a companion to the Calendar and
-Contacts Server in the same Mac OS Forge project), which performs more
-"black box"-type testing against the server to ensure compliance with
-the CalDAV protocol. That requires running the server with a test
-configuration and then running CalDAVTester against it. For
-information about CalDAVTester is available here:
-
- https://github.com/apple/ccs-caldavtester
</del></span></pre></div>
<a id="CalendarServertrunkHACKINGrst"></a>
<div class="modfile"><h4>Modified: CalendarServer/trunk/HACKING.rst (15513 => 15514)</h4>
<pre class="diff"><span>
<span class="info">--- CalendarServer/trunk/HACKING.rst        2016-04-18 15:20:08 UTC (rev 15513)
+++ CalendarServer/trunk/HACKING.rst        2016-04-18 16:10:04 UTC (rev 15514)
</span><span class="lines">@@ -1,5 +1,5 @@
</span><del>-Developer's Guide to Hacking the Calendar Server
-================================================
</del><ins>+Developer's Guide to Contributing to the Calendar Server
+========================================================
</ins><span class="cx">
</span><span class="cx"> If you are interested in contributing to the Calendar and Contacts
</span><span class="cx"> Server project, please read this document.
</span><span class="lines">@@ -8,28 +8,30 @@
</span><span class="cx"> Participating in the Community
</span><span class="cx"> ==============================
</span><span class="cx">
</span><del>-Although the Calendar and Contacts Server is sponsored and hosted by
-Apple Inc. (http://www.apple.com/), it's a true open-source project
-under an Apache license. Contributions from other developers are
-welcome, and, as with all open development projects, may lead to
-"commit access" and a voice in the future of the project.
</del><ins>+The Calendar and Contacts Server began in 1996 -- an open source
+project sponsored and hosted by Apple Inc. (http://www.apple.com/).
+The project is now hosted at GitHub, and although it lives within
+the "apple" namespace it's still a true open-source project under
+an Apache license. Contributions from other developers are welcome,
+and, as with all open development projects, may lead to "commit
+access" and a voice in the future of the project.
</ins><span class="cx">
</span><del>-The community exists mainly through mailing lists and a Subversion
</del><ins>+The community exists mainly through mailing lists and a GitHub
</ins><span class="cx"> repository. To participate, go to:
</span><span class="cx">
</span><del>- http://trac.calendarserver.org/projects/calendarserver/wiki/MailLists
</del><ins>+ https://trac.calendarserver.org/wiki/MailLists
</ins><span class="cx">
</span><span class="cx"> and join the appropriate mailing lists. We also use IRC, as described
</span><span class="cx"> here:
</span><span class="cx">
</span><del>- http://trac.calendarserver.org/projects/calendarserver/wiki/IRC
</del><ins>+ https://trac.calendarserver.org/wiki/IRC
</ins><span class="cx">
</span><span class="cx"> There are many ways to join the project. One may write code, test the
</span><span class="cx"> software and file bugs, write documentation, etc.
</span><span class="cx">
</span><del>-The bug tracking database is here:
</del><ins>+The issue tracking database is here:
</ins><span class="cx">
</span><del>- http://trac.calendarserver.org/projects/calendarserver/report
</del><ins>+ https://github.com/apple/ccs-calendarserver/issues
</ins><span class="cx">
</span><span class="cx"> To help manage the issues database, read over the issue summaries,
</span><span class="cx"> looking and testing for issues that are either invalid, or are
</span><span class="lines">@@ -38,8 +40,9 @@
</span><span class="cx"> changes in the code, and the second because people sometimes file an
</span><span class="cx"> issue without noticing that it has already been reported. If you are
</span><span class="cx"> not sure about an issue, post a question to
</span><del>-calendarserver-dev@lists.macosforge.org.
</del><span class="cx">
</span><ins>+ calendarserver-dev@lists.macosforge.org.
+
</ins><span class="cx"> Before filing bugs, please take a moment to perform a quick search to
</span><span class="cx"> see if someone else has already filed your bug. In that case, add a
</span><span class="cx"> comment to the existing bug if appropriate and monitor it, rather than
</span><span class="lines">@@ -50,26 +53,11 @@
</span><span class="cx"> ==================
</span><span class="cx">
</span><span class="cx"> The source code to the Calendar and Contacts Server is available via
</span><del>-Subversion at this repository URL:
</del><ins>+Git at this repository URL:
</ins><span class="cx">
</span><del>- http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/
</del><ins>+ https://github.com/apple/ccs-calendarserver.git
</ins><span class="cx">
</span><del>-You can also browse the repository directly using your web browser, or
-use WebDAV clients to browse the repository, such as Mac OS X's Finder
-(`Go -> Connect to Server`).
</del><span class="cx">
</span><del>-A richer web interface which provides access to version history and
-logs is available via Trac here:
-
- http://trac.calendarserver.org/browser/
-
-Most developers will want to use a full-featured Subversion client.
-More information about Subversion, including documentation and client
-download instructions, is available from the Subversion project:
-
- http://subversion.tigris.org/
-
-
</del><span class="cx"> Directory Layout
</span><span class="cx"> ================
</span><span class="cx">
</span><span class="lines">@@ -87,8 +75,6 @@
</span><span class="cx">
</span><span class="cx"> * ``twistedcaldav/`` - Source code for CalDAV library
</span><span class="cx">
</span><del>- * ``twistedcaldav/`` - Source code for extensions to Twisted
-
</del><span class="cx"> * ``twisted/`` - Files required to set up the Calendar and Contacts
</span><span class="cx"> Server as a Twisted service. Twisted (http://twistedmatrix.com/)
</span><span class="cx"> is a networking framework upon which the Calendar and Contacts
</span><span class="lines">@@ -123,14 +109,14 @@
</span><span class="cx">
</span><span class="cx"> Read PEP-8:
</span><span class="cx">
</span><del>- http://www.python.org/dev/peps/pep-0008/
</del><ins>+ https://www.python.org/dev/peps/pep-0008/
</ins><span class="cx">
</span><span class="cx"> For the most part, our code should follow PEP-8, with a few exceptions
</span><span class="cx"> and a few additions. It is also useful to review the Twisted Coding
</span><span class="cx"> Standard, from which we borrow some standards, though we don't
</span><span class="cx"> strictly follow it:
</span><span class="cx">
</span><del>- http://twistedmatrix.com/trac/browser/trunk/doc/development/policy/coding-standard.xhtml?format=raw
</del><ins>+ https://twistedmatrix.com/documents/current/core/development/policy/coding-standard.html
</ins><span class="cx">
</span><span class="cx"> Key items to follow, and specifics:
</span><span class="cx">
</span><span class="lines">@@ -422,34 +408,14 @@
</span><span class="cx"> module names should start with ``test_``. Twisted has some tips on
</span><span class="cx"> writing tests here:
</span><span class="cx">
</span><del>- http://twistedmatrix.com/projects/core/documentation/howto/testing.html
</del><ins>+ https://twistedmatrix.com/documents/current/core/howto/testing.html
</ins><span class="cx">
</span><del>- http://twistedmatrix.com/trac/browser/trunk/doc/development/policy/test-standard.xhtml?format=raw
</del><ins>+ https://twistedmatrix.com/documents/current/core/development/policy/test-standard.html
</ins><span class="cx">
</span><span class="cx"> We also use CalDAVTester (which is a companion to the Calendar and
</span><del>-Contacts Server in the same Mac OS Forge project), which performs more
-"black box"-type testing against the server to ensure compliance with
-the CalDAV protocol. That requires running the server with a test
-configuration and then running CalDAVTester against it. For
-information about CalDAVTester is available here:
</del><ins>+Contacts Server), which performs more "black box"-type testing against
+the server to ensure compliance with the CalDAV protocol. That requires
+running the server with a test configuration and then running
+CalDAVTester against it. Information about CalDAVTester is available here:
</ins><span class="cx">
</span><del>- http://trac.calendarserver.org/projects/calendarserver/wiki/CalDAVTester
-
-
-Commit Policy
-=============
-
-We follow a commit-then-review policy for relatively "safe" changes to
-the code. If you have a rather straightforward change or are working
-on new functionality that does not affect existing functionality, you
-can commit that code without review at your discretion.
-
-Developers are encouraged to monitor the commit notifications that are
-sent via email after each commit and review/critique/comment on
-modifications as appropriate.
-
-Any changes that impact existing functionality should be reviewed by
-another developer before being committed. Large changes should be
-made on a branch and merged after review.
-
-This policy relies on the discretion of committers.
</del><ins>+ https://github.com/apple/ccs-caldavtester
</ins></span></pre>
</div>
</div>
</body>
</html>