This wiki is archived and useful information is being migrated to the main bzflag.org website
Difference between revisions of "Category:Development"
(Add notes on the various dev templates and when each should be used, and point out the patch tracker for submissions of code for new ideas)
|Line 9:||Line 9:|
Scott Wichser (Blast007) and
Scott Wichser (Blast007) and () are the development leads. They are responsible for the day to day development and planning of the various releases of BZFlag. They maintain the [[BZFlag Source]] Code, [[BZFlag_SVN|SVN]] repository, and ensure that development of the game goes according to the design goals and [[Development_RoadMap]].
Revision as of 18:45, 12 April 2015
BZFlag is developed as an open source guided development process involving a number of developers all over the world.
Open source development tends to not have as formal a structure as traditional development, but the bzflag project does have a group of developers that are responsible for various aspects of projet.
Tim Riker (TimRiker) is the copyright holder and intellectual property manager for the project and manages its various legal operations.
Scott Wichser (Blast007) and Jeff Makey (Bullet Catcher) are the development leads. They are responsible for the day to day development and planning of the various releases of BZFlag. They maintain the BZFlag Source Code, SVN repository, and ensure that development of the game goes according to the design goals and Development_RoadMap.
Scott Wichser (Blast007) and Joe Vano (JoeVano) manage the public services that BZFlag clients and servers use such as the List Server and Global Registration System.
A number of community members maintain the BZFlag Forums including;
- Bullet Catcher
Development communications mostly happens in the BZFlag IRC channel. There are development mailing lists on the sourceforge site but they are rarely used. Many developers are often on the IRC channel and are more then willing to discuss things relating to bzflag development.
BZFlag has a documented coding policy that is in the DEVINFO file that is included with every source code release.
Wiki Development Design Templates
In order to help out developers in building collaborative documents, the wiki has several templates that can be used to setup documents.
IdeaDesign This template is intended to be used to flesh out an idea or proposed change that has not yet been accepted but is being worked on by multiple people. This is where all new ideas should start.
DesignDocument Once an idea or change has been approved and made part of the development plan it will be changed to a Design Document. This indicates that the feature can be worked on in the development codebase by any developer.
Specification If additional documentation is needed for a feature then those documents can use this template. Specifications should also be put into a category or name space with the associated design document overview.
Notes on Patches
Some ideas may not be accepted by the development community right away, if the idea proposer wishes to implement the idea or parts of the idea to prove it out then those changes should be submitted to the SourceForge Patch Tracker. This will allow developers and team leaders to review the patch and decide if it should be included in the mainline release. It also lets other use or extend the code changes for private use.
SVN repository stored on Source Forge.
BZFlag Source Information on the source code for the game.
BZFS API Information on the API for plug-in development.
SourceForge Patch Tracker where code changes from new developers are submitted.
SourceForge Bug Tracker where users report bugs or problems in the game.
SourceForge Feature Requests where users request new features ( pending approval).
BZFlag can always use new developers. Users that wish to become more involved in the development process are encouraged to join the IRC channel and talk to the developers and players there.
The next step is to submit patches to the patch tracker so the new developer can get the hang of how the codebase works and so that project management can evaluate the coding ability/style of the new developer. The best way to get started is to take a look at the bugs in the Bug Tracker.
If a new developer fits into the project well and is productive they will often be given commit access to the SVN system so they may make changes directly to the code.
The current shipping version is based on the 2.4.2 tag tags/v2_4_2/ in svn
The current development version is 2.4.3 and is maintenance for the 2.4.x line, it is located in trunk/bzflag in svn.
This category has the following 2 subcategories, out of 2 total.
Pages in category "Development"
The following 24 pages are in this category, out of 24 total.