Development Team/policy

Revision as of 19:32, 28 May 2009

This document describes how DareNET's Development Team should function. The formal procedures it uses, the position of the people it is composed of, and the tasks it should accomplish. It will be the reference set of rules use by the team.

Tasks

The DareNET Development Team (hereafter called dev-team or simply 'the team') is in charge of maintaining, debugging, upgrading and improving the code of ircd-darenet (including protocol used for server<>server communication and for client<>server commication), and other projects such as services-darenet, website-darenet, plugins-darenet and webchat-darenet. The team may also oversee other projects where considered desirable by DareNET's Executive Board.

It is formally accepted that any material (code and documentation) produced by the team is to be considered closed source, and is not to be distributed outside of DareNET. Should a decision be made to release any said material, it must be released under the GNU General Public License (GPL). What is not GPL is beyond the scope of the team and is released and maintained elsewhere.

Similarly, it must be clear, and understood by all team members, that the main scope of the team is to develop the code for use by DareNET, so only those changes, features and/or services used by DareNET are part of the work of the team.

Goals

The major goals of the team are (in descending order of priority):

• Diagnosing and removing bugs in the current code.
• Improving the performance of the code used for DareNET.
• Making the code base more stable, more consistent and likewise, more maintainable.
• Documenting both existing and newly written code (e.g. using Doxygen-compatible comments).
• Adding services and features while keeping backwards compatibility with existing servers, clients and formal or informal standards.
• Developing new features for client use in cooperation with the developers of the major clients.

Members

The team has different kinds of members with different roles: a manager, maintainers, a small group of senior coders, and group of helpers/contributors (hopefully!).

Development Manager

The Development Manager oversees the entire team, including its various projects and members. He or she (hereafter labeled "he" for brevity, not sexism) is mostly concerned with ensuring the team's various projects meet established deadlines, and handling any disciplinary issues that may arise.

Maintainers

Each project has a maintainer. The maintainer is the one responsible for keeping the integrity of the code base. He must be an experienced coder and know the internals of the project in detail.

The maintainer is the only one who has direct shell access to SVN (though this may be delegated to others) and is responsible for maintaining and administering the repository. It is one of his major duties to keep things synch'd and verify that any change doesn't break the code or protocol. The maintainer, of course, may attempt to reduce his workload by distributing what can be delegated to others.

The maintainer's decisions about actual coding matters take place with a "silent agreement" procedure, as long as there are no objections, and temporarily hold if a formal vote is later held.

Senior Coders

Senior coders are the most experienced and trusted coders that put the biggest effort into the team's various projects. They are the only other members of the team that may have commit access to the svn repository. The manager and maintainers are implicitly senior coders.

Helpers / Contributors

Everyone willing to contribute to the work of the team can be a contributor.

Contributors do not have commit access to the repositories, and they can't submit patches directly to the maintainers (if there are other senior coders on the project). Instead, they must follow the specific procedure for submitting patches, described below, in order to save some of the maintainer's time when checking patches.

Tasks of the contributors include:

• Trying to help those who have trouble running or compiling the daemon, or answering the easier questions asked on the forums.
• Replying to those who make fuzzy feature requests on the forums, and eventually trying to interpret such requests and finding out if/how they can become realistic proposals.
• Working on documentation.
• Submitting patches.

A helper can be given access to posting to dev@ and/or the development forum, after recommendation by a senior coder, and that would happen after an informal vote, pending no objections by other senior coders.

Forums & IRC Channel

As a means of communication between the members, the team will use the forums and IRC channel.

Development Forum

All team members will have access to the development forum located on the DareNET forums website. It is there that senior coders can discuss changes to the project's code base, make informal votes and so on.

The forum is directly managed by the Development Team Manager.

Contributors can join the forum provided there are no objections by senior coders.

#Dev

#Dev will be the team's official IRC channel. It is recommended that members of all projects join this channel to allow for easy cross-project discussion and interaction.

dev@darenet.org

This list is the place for users to report bugs. Here the senior coders might also discuss how deal with the most critical bugs.

The list is directly managed by the Development Team Manager.

Only senior coders may be subscribed to this list; however, the list is open for posting by anyone.

Procedures

Procedures for the tasks of them team should be kept as simple and informal as possible; however, a minimum number of organizational details and formalities are needed to keep control.

Any decision taken by the team follows one of these three paths: silent agreement, informal voting, or formal voting. The idea is that if there are not severe objections for something, it can be decided with silent agreement (that is, agreement is not reached if there are any objections). If some objection arises, an informal voting is asked by the manager on the closed dev@ list, and only as a last resort and/or for really major decisions the manager may issue a formal cfv.

Moreover, most common actions of the team should follow a defined procedural path, thought to simplify things and improve the stability of the code produced, its consistency, and the cooperation within the group.

Approval of patches

Patches can be submitted by anybody, but the path they follow before being approved changes based on who proposes them.

Patches are those code submissions that don't severely alter the "behavior" of the server but only how it internally works; major changes follow a different procedure described later.

A patch must be submitted with a separate description section that includes standard header fields, and the actual patch should be in "diff-rc3" format. The manager can ask that the description of the patch and other information are provided in a standard form that can be somehow automatically processed and archived, if he so chooses.

When a patch is prepared by one of the senior coders or from one of the trusted helpers, he can send it directly to the manager or, preferrably, send it to the dev@ list (and it is advisable that he let the dev@ list know what he is up to before writing the patch). The manager should quickly verify it and then follow one of the following three steps. If the patch seems ok to him, the senior coder puts it in the repository. Otherwise, the manager could have found some problem with the patch, in which case he can either discuss privately the issue with the author until they find an agreement or ask for an informal vote on the list while keeping the patch suspended.

Finally, when a patch is submitted by a helper he has to contact first one of the senior coders, who will act as a "sponsor" for the patch and has the duty of verifying its behavior, personally testing it, checking for interference with other parts of the code, and fixing problems. If he finds the patch working and helpful, he posts it as "written by x, verified by me." This is to save the manager from the work of checking patches that are broken, unacceptable, or that break the protocol of the choices made by dev-team.

Approval of formal releases

The coding tasks of the team move toward two different directions:

• Preparation of new releases
• Bug fixing

All optimization efforts, addition of new features, and protocol changes should be considered part of the "next major release". Thus the SVN should be divided into two parts: a stable working release (branches) and an "experimental" unstable release (trunk).

Most patches should be included only in trunk. When trunk has been found stable it can be formally released as stable.

Upon proposal by the manager, a formal vote takes place to make the current trunk version the next stable formal release, and following that the manager prepares a tarball of the release to be submitted to the Server Management team that will become the "required" codebase for DareNET servers. Thus all patches included in the SVN should not be adopted in the network until the next formal release has been produced and approved.

An exceptional path is to be adopted for bug fixes considered urgent in the production network. When such a bug is found and a patch is prepared for it, the manager will post two different patches: one for trunk and one for the branch. The patch in branch should be applied as soon as possible by all the servers on the production network to fix the bug while waiting for the next formal release.

Approval of protocol/semantic changes

Some changes in the source tree can't be done with simple patches because they have a major impact on the network, and the following are examples:

• Changes to the server<>server protocol's syntax or semantics.
• Changes in the client<>server protocol that can break existing clients (like the removal of commands or the change of their behavior that cause any command that worked and produced a given effect with some parameters to behave differently or not work anymore with the same parameters and under the same conditions).
• Addition of commands of features that might somehow violate any of the rules of the network (like allowing people to spam more, to have access to information they couldn't access before, to hide information that they couldn't hide before and so on).

Such changes need to be approved by a formal vote on dev@ and then forwarded for ratification to the Operations Director, and eventually the Executive Board.

Moreover changes in server<>server protocol should always be checked in advance with the coders/manager of the services linked to the network, and as far as possible changes in the client<>server protocol should always be checked in advance with the coders of the major clients and of the daemons of the other major networks. On this last subject DareNET will make any effort to promote cooperation with the coders of other major networks and of the most commonly used clients.