The Coordinated Wesnoth UMC Development project (also known as wesnoth-umc-dev) at SourceForge.net is aimed to solve these issues that were formerly solved by the means of abusing the WesCamp-i18n project storage space and work cycle. Abusing, indeed; that project's only goal was to provide a repository for development and coordination of UMC internationalization, not for artwork, polishing, and other equally important points.
The purpose of the wesnoth-umc-dev project is to provide a shared repository for collaboration on Wesnoth UMC development. Having your project in this repo also means it will be periodically backed up, its change history will be preserved, and someone else can take it up if you abandon it.
The project administrators are shadowmaster/ShikadiLord (inactive), AI0867 and Espreon; these are the ones who you should contact to gain commit access. Because not every add-on can get in, they must comply with the following policy:
- All content allowed inside the repository must be distributable, modifiable and reusable under a license conforming to the Open Source Definition; to reduce complexity, we recommend GPL v2 or v3. In the case of music, sounds, graphics and other binary resource files, as an special exception to the GNU GPL, the "source code" of those files is considered to be the files themselves.
- This is not a general-purpose repository. Only material necessary and relevant for UMC development is allowed. That includes: WML; scripts for the Python AI; UMC maintainance scripts; and audio/video files in open, patent-free formats. It excludes platform-dependent cruft such as Thumbs.db files (Windows shell thumbnail cache), .raw files and closed-format image and audio files. PSDs are a special (permitted) exception since the GIMP is mostly compatible with the format.
- Artwork and content: You must abide by the SourceForge terms of service forbidding copyright violations and material which would be considered obscene, slanderous, or otherwise in violation of the law where the servers are hosted (California, USA). Use your common sense; if in doubt, ask an administrator before uploading.
- Object-code and executable binary programs: these are not allowed, since they (a) are of limited usefulness, (b) are generally larger than the parent source-code program, and (c) source code available in the same repository is required to comply with the terms of the GPL.
- Vandalism and cracking tools are strictly prohibited and will be considered cause to immediately revoke your repository write access.
Developers should also note the following:
- Technically, developers of one add-on are free to modify other add-ons' code. However, as a matter of respect and politeness, you should always ask before touching other people's work to do anything more than repairing obvious errors. Use your common sense, remember that all modifications are tracked, and that defacing another's work could get you kicked off.
- The repo maintainers may from time to time apply tools such as wmllint, wmlindent, and optipng to your content. This is normal and intended to maintain a high level of code quality and readability. If you apply them yourself, we won't have to surprise and possibly inconvenience you by doing it.
- Campaigns, eras, and other modules should use new-style organization in which all files for a campaign named 'Foo bar' live under a directory named Foo_bar with the main WML file as _main.cfg directly beneath it. The old style in which the main WML file would be named Foo_bar.cfg and be at the same level as the campaign directory is deprecated; if you submit an add-on in this form, it will be changed to the new style.
- You should not check the .pbl password file for your addon into the repository, as this exposes your password to anyone with read access and could result in your content being vandalized on the add-on server.
- We recommend that all developers subscribe to our commit mailing list, wesnoth-umc-dev-commits. See the project page, "Mailing Lists" menu, for information.
- We also recommend that all developers regularly monitor the #wesnoth-umc-dev channel on irc.wesnoth.org
How to get your add-on included:
- Get a working SourceForge.net account.
- Apply to a wesnoth-dev-umc administrator for access. In your application must (a) agree to these terms of service, (b) provide an initial copy of your add-on for us to audit, and (c) tell us which version of Wesnoth it is intended for (which will tell us where to put it in the repo.)
You may contact an administrator by email or PM on the Wesnoth forums; we encourage PMs. If and when your application is accepted, we will check in your add-on and grant you commit access,
Directory hierarchy and tagging
The SVN root contains only three directories, which are branches, trunk and tags. The branches directory is separated into Wesnoth branch versions, such as '1.0', '1.2', '1.4'. UMC is placed under whichever branch matches the game engine branch that the add-on is designed and developed for. Therefore, the content related to a campaign named "Son of Haldric I" developed for Wesnoth 1.4 will be placed under /branches/1.4/Son_of_Haldric_I/.
The /trunk tree contains UMC developed for the current Wesnoth development version, which is equivalent to the mainline SVN trunk version. Your UMC can be located both in a branch (or branches) and trunk if need be, and you can maintain it fo different versions of Wesnoth. Our example campaign's files would then be placed under /trunk/Son_of_Haldric_I/ as well as their 1.4 branch location.
The /tags tree is special. It should not contain ever-changing content, but rather release tags, about which you should refer to the SVN book for details. They are a very good idea for bookkeeping, but don't try to use them as your primary release source for your users, since that will only consume extra repository bandwidth. Using them to coordinate releases amongst your add-on's maintainers is fine, as long but try to keep the number of tags small as they nulk up the repository. Release 8.9.2 of our example campaign for 1.4 would be a tag of revision 310's (or whatever) state of /branches/1.4/Son_of_Haldric_I/ located at /tags/1.4/Son_of_Haldric_I/8.9.2/.
Shadow Master created an IRC channel for the project, #wesnoth-umc-dev at irc.freenode.net. You can ask general questions about the project there, about add-ons hosted by us, or Subversion usage. You can use the channel to ask general WML questions too.
Having said all that, I recommend reading (and downloading, if you need it) the free SVN book (http://svnbook.org/) carefully before contacting us for help with usage (or troubleshooting) of Subversion.
Bugs, features and patches
We have enabled the bug tracker, feature request tracker, and patch trackers for the whole Wesnoth-UMC-Dev project. At the moment, artifacts may be classified only for certain add-ons/categories:
* Invasion from the Unknown
* Delfador's Memoirs
* The Silver Lands
* Unrest in Elfland
The trackers' may be found at https://sourceforge.net/tracker/?group_id=221284. Non-authenticated posts are not allowed in order to avoid spam. Posts not pertaining to any of the above categories will be removed in sight.