Difference between revisions of "DeveloperGuide"

From The Battle for Wesnoth Wiki
m
(Improve svn commits recommandations)
Line 1: Line 1:
* setting up developer SVN access: https://gna.org/svn/?group=wesnoth
+
== Commits ==
* Keep the commit easy to revert if need be
+
* Setting up developer SVN access: [[WesnothSVN#Commit_access]]
* no huge commit (hard to review), so when possible maybe split it in working part with info about where you are going
+
* Register to commit mailing list: https://mail.gna.org/listinfo/wesnoth-commits or get the list moderator to approve commit messages from you otherwise
* be on #wesnoth-dev IRC channel and coordinate with other developers
+
* Trunk should compile and work after commit
* code should compile and work after commit
+
* Few small commits are better than a big one (hard to review), so when possible split it in working parts with info about where you are going
* Don't mess with the art or music without approval from one of the art and music people.
+
* Be on #wesnoth-dev IRC channel and coordinate with other developers. Bots report commits and some devs may ask you a question about it.
* clear commit message (can be several lines)
+
* Don't forget changelogs: ''changelog'' for any (significant enough) changes and ''player_changelog'' for changes visible to users.
* mention "bug #1234" in the commit message for automatic cc to that gna bug number
+
* Always check your changes before commit (use ''svn diff'')
* don't forget changelog
+
* Commit message:
* change status of fixed bugs to "Fixed" when committed
+
** Mention any change, especially if some are unrelated to the main one (but you should use separated commits for this).
* change status of fixed bugs to "Closed" when released, see [[ReportingBugs#Bug_protocol]] for details
+
** Mention "bug #1234" for automatic cc to that gna bug number
* register to commit mailing list: https://mail.gna.org/listinfo/wesnoth-commits
+
** Mention a developer's IRC name will ping him on IRC (when the bot report it), and if he's not there, he may see it on the IRC logs
** or get the list moderator to approve commit messages from you otherwise
+
== Bugs management ==
* don't forget http://www.wesnoth.org/wiki/EasyCoding if you're ever out of ideas :)
+
* Change status of fixed bugs to "Fixed" when committed
 
+
* Change status of fixed bugs to "Closed" when released, see [[ReportingBugs#Bug_protocol]] for details
* threading model: SDL threads via src/thread.hpp
+
* Check if there is new bugs relevant to your code and if any, assign them to you.
** synchronization model
 
*** avoid multi-threading code as much as possible
 
*** if you don't see threading code you probably don't need to learn about it
 
  
 
== See also ==
 
== See also ==

Revision as of 14:47, 1 August 2010

Commits

  • Setting up developer SVN access: WesnothSVN#Commit_access
  • Register to commit mailing list: https://mail.gna.org/listinfo/wesnoth-commits or get the list moderator to approve commit messages from you otherwise
  • Trunk should compile and work after commit
  • Few small commits are better than a big one (hard to review), so when possible split it in working parts with info about where you are going
  • Be on #wesnoth-dev IRC channel and coordinate with other developers. Bots report commits and some devs may ask you a question about it.
  • Don't forget changelogs: changelog for any (significant enough) changes and player_changelog for changes visible to users.
  • Always check your changes before commit (use svn diff)
  • Commit message:
    • Mention any change, especially if some are unrelated to the main one (but you should use separated commits for this).
    • Mention "bug #1234" for automatic cc to that gna bug number
    • Mention a developer's IRC name will ping him on IRC (when the bot report it), and if he's not there, he may see it on the IRC logs

Bugs management

  • Change status of fixed bugs to "Fixed" when committed
  • Change status of fixed bugs to "Closed" when released, see ReportingBugs#Bug_protocol for details
  • Check if there is new bugs relevant to your code and if any, assign them to you.

See also