<liclass="toctree-l2"><aclass="reference internal"href="#how-to-submit-stuff-for-inclusion-into-upstream-cdist">29.4. How to submit stuff for inclusion into upstream cdist</a></li>
<liclass="toctree-l2"><aclass="reference internal"href="#how-to-submit-a-new-type">29.5. How to submit a new type</a></li>
<liclass="toctree-l2"><aclass="reference internal"href="#example-git-workflow">29.6. Example git workflow</a></li>
<h2><spanclass="section-number">29.3. </span>Coding conventions (everywhere)<aclass="headerlink"href="#coding-conventions-everywhere"title="Permalink to this headline">¶</a></h2>
<p>If something should be improved or needs to be fixed, add the word FIXME
nearby, so grepping for FIXME gives all positions that need to be fixed.</p>
<p>Indentation is 4 spaces (welcome to the python world).</p>
<h2><spanclass="section-number">29.4. </span>How to submit stuff for inclusion into upstream cdist<aclass="headerlink"href="#how-to-submit-stuff-for-inclusion-into-upstream-cdist"title="Permalink to this headline">¶</a></h2>
<p>If you did some cool changes to cdist, which you think might be of benefit to other
cdist users, you're welcome to propose inclusion into upstream.</p>
<p>There are some requirements to ensure your changes don't break other peoples
work nor kill the authors brain:</p>
<ul>
<li><p>All files should contain the usual header (Author, Copying, etc.)</p></li>
<li><p>Code submission must be done via git</p></li>
<li><p>Do not add cdist/conf/manifest/init - This file should only be touched in your
private branch!</p></li>
<li><p>Code to be included should be branched of the upstream "master" branch</p>
<blockquote>
<div><ulclass="simple">
<li><p>Exception: Bugfixes to a version branch</p></li>
</ul>
</div></blockquote>
</li>
<li><p>On a merge request, always name the branch I should pull from</p></li>
<li><p>Always ensure <strong>all</strong> manpages build. Use <strong>./build man</strong> to test.</p></li>
<li><p>If you developed more than <strong>one</strong> feature, consider submitting them in
separate branches. This way one feature can already be included, even if
the other needs to be improved.</p></li>
</ul>
<p>As soon as your work meets these requirements, write a mail
for inclusion to the mailinglist <strong>cdist-configuration-management at googlegroups.com</strong>
or open a merge request at <aclass="reference external"href="https://code.ungleich.ch/ungleich-public/cdist">https://code.ungleich.ch/ungleich-public/cdist</a>.</p>
</div>
<divclass="section"id="how-to-submit-a-new-type">
<h2><spanclass="section-number">29.5. </span>How to submit a new type<aclass="headerlink"href="#how-to-submit-a-new-type"title="Permalink to this headline">¶</a></h2>
<p>For detailed information about types, see <aclass="reference external"href="cdist-type.html">cdist type</a>.</p>
<p>Submitting a type works as described above, with the additional requirement
that a corresponding manpage named man.rst in ReSTructured text format with
the manpage-name "cdist-type__NAME" is included in the type directory
AND the manpage builds (<cite>make man</cite>).</p>
<p>Warning: Submitting "exec" or "run" types that simply echo their parameter in
<strong>gencode</strong> will not be accepted, because they are of no use. Every type can output
code and thus such a type introduces redundant functionality that is given by
core cdist already.</p>
</div>
<divclass="section"id="example-git-workflow">
<h2><spanclass="section-number">29.6. </span>Example git workflow<aclass="headerlink"href="#example-git-workflow"title="Permalink to this headline">¶</a></h2>
<p>The following workflow works fine for most developers</p>
<divclass="highlight-sh notranslate"><divclass="highlight"><pre><span></span><spanclass="c1"># get latest upstream master branch</span>
Built with <ahref="http://sphinx-doc.org/">Sphinx</a> using a <ahref="https://github.com/rtfd/sphinx_rtd_theme">theme</a> provided by <ahref="https://readthedocs.org">Read the Docs</a>.