Xfce Wiki

Sub domains
 

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
dev:howto:contribute [2013/02/02 13:48] – [Contribution Process] jannisdev:howto:contribute [2013/02/02 16:04] – [Contribution Process] jannis
Line 44: Line 44:
  
   * Make sure to commit frequently.   * Make sure to commit frequently.
 +  * Make sure to pull in the latest Xfce master frequently.
   * Keep commits clean:   * Keep commits clean:
-    * Make incremental, atomic changes (one aspect at a time) +    * Make incremental, atomic changes (one aspect at a time). 
-    * Keep code working after every commit +    * Keep code working after every commit. 
-    * Comment the code you write +    * Comment the code you write. 
-    * Write commit messages using the standard Git message format +    * Write commit messages using the standard Git message format. 
-    * Don't fear the rebase (against master) to reorder, reorganize and rewrite your branch to keep it clean+    * Don't fear the rebase (against the Xfce master branch).
  
 === 3. Push === === 3. Push ===
  
-Before submitting your changes for review, it is a good idea to push them to a public repository, e.g. on GitHub. This will make it easier for others to check out your branch and test it as part of their reviews.+Before submitting your changes for review, it is a good idea to push them to a public repository, e.g. on GitHub. This will make it easier for others to check out your branch and test it as part of their reviews. It also simplifies the merging process.
  
 === 4. Submit for review === === 4. Submit for review ===
  
-Submitting your changes for review is as simple as running a single Git command. In your branch, run:+Submitting your changes for review is as simple as running a single command. In your branch, run:
  
   git send-email --suppress-cc=self --annotate --cover-letter origin/master --to=xfce4-dev@xfce.org   git send-email --suppress-cc=self --annotate --cover-letter origin/master --to=xfce4-dev@xfce.org
Line 73: Line 74:
  
 Fill out the SUBJECT and MESSAGE by briefly describing what you are submitting. Then save the file and close the editor. ''git send-email'' will send your patch set to the ''xfce4-dev@xfce.org'' mailing list in the form of the above cover letter email, followed by an additional email for each commit in your branch. These mails will each include the commit message and the commit diff as plain text. Fill out the SUBJECT and MESSAGE by briefly describing what you are submitting. Then save the file and close the editor. ''git send-email'' will send your patch set to the ''xfce4-dev@xfce.org'' mailing list in the form of the above cover letter email, followed by an additional email for each commit in your branch. These mails will each include the commit message and the commit diff as plain text.
 +
 +**Configuring ''git send-email''**
 +
 +You will need to configure a number of items for ''git send-email'' to function usefully. At minimum, you need to tell it how to actually send emails. This can be done with the following
 +
 +  git config --global sendemail.smtpserver mail.example.com
 +  git config --global sendemail.smtpserverport 25
 +
 +If you need encryption to use your mail server, set:
 +
 +  git config --global sendemail.smtpencryption starttls
 +
 +If you need to log in to your server, you can set the user name in the config and then git send-email will prompt you for the password during the sending process.
 +
 +  git config --global sendemail.smtpuser yourmailusername
 +
 +You need to teach git send-email what name and address to send the emails from. This might need to change from project to project, but if not, then:
 +
 +  git config --global sendemail.from "$(git config user.name) <$(git config user.email)>"
  
 === 5. Review === === 5. Review ===
Line 80: Line 100:
   * Testing the changes.   * Testing the changes.
   * Comments on:   * Comments on:
-    * Coding style and bad code design +    * Coding style and bad code design. 
-    * Potential issues +    * Potential issues. 
-    * Possible side-effects+    * Possible side-effects.
  
 The reviews will be sent as replies to your cover letter and patch emails. Thanks to having the patches included in your submission as plain text, they can be commented on in-line. The reviews will be sent as replies to your cover letter and patch emails. Thanks to having the patches included in your submission as plain text, they can be commented on in-line.