Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="note"><ac:parameter ac:name="title">Draft</ac:parameter><ac:rich-text-body>
<p>Please note that this page is still a draft and therefore no (dramatic) conclusions should be drawn based on this. Unless the conclusion is that we're busy.</p></ac:rich-text-body></ac:macro>

<h1>Introduction</h1>
<p>This page describes the workflows that will be used for contributing code. The idea is that someone writes code, some magic happens, and the code gets released with the Zend Framework. This page aims at explaining the magic part.</p>

<h3>Git pull request.</h3>
<p>Scenario: Someone does have a public git repo (e.g. on github) and has fixed a bug in his own repo.</p>

<p>The committer can then file a pull request and email that. By starting the subject with an issue id, the review control system (RCS) can automatically determine who is/are the maintainer(s) of the component(s) that is/are affected by the commit (example.com should probably be replaced with framework.zend.com).</p>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[git request-pull <commit-hash> <git-uri> | \
/usr/bin/mail -a "From: yourAddress@example.com" -s "ZF-77777 <commit description>" commits@example.com]]></ac:plain-text-body></ac:macro>

<p>The request is then automatically aggregated by the review control system. If the from address is unknown to jira, or does not have a CLA on file, it will be automatically refused; meaning the system replies to the email explaining the problem.</p>

<p>If the email address belongs to a user that is not a maintainer of the component in question (based on the issue id), the maintainer will automatically receive an email in which he is asked to review the commit in the RCS. If he/she <span style="text-decoration: line-through;">approves it, or</span> doesn't look at it within seven days; a CR-team member will review it. When a maintainer commits code, the CR-Team will review it. Once the CR-team approves it; it either is pushed into the master, or a pull request is sent to MWOP (TBD).</p>

<h3>Patches</h3>
<p>For patches a similar workflow as with pull requests is used, but a different command for sending it should be used. Probably something like:</p>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[git diff | \
/usr/bin/mail -a "From: yourAddress@example.com" -s "ZF-77777 <commit description>" commits@example.com]]></ac:plain-text-body></ac:macro>

<p>Patches should only be attached to an issue in jira if they're open for discussion, so discussion can take place with all involved contributors in jira. <strong>After</strong> that discussion, the assignee should file the patch as noted above, making sure it gets into the RCS.</p>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jun 18, 2010

    <p>Thank you for writing this page Dolf. Before this a person was thrown in the deap without any clear written workflows, which can be quite demotivating.</p>