Development Team

This document gives a brief breakdown on how DareNET's development team, in regards to IRCd & Services, should work. It shall be the reference set of rules used 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 communication, the code related to additional services linked as different daemons (such as services-darenet) where it is considered desirable by the Executive Board, and the documentation of all the above.

It is formally accepted that code produced by the team is to be considered closed source, and is not to be distributed outside of DareNET's Operations Department.

Similarly, it must be clear that the main scope of the team is to develop the code for DareNET, so only those changes, features 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 server code used for DareNET.
• Making the codebase more stable, more consistent, and likewise, more maintainable.
• Documenting both existing and newly written code.
• 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 IRC clients.

Members

The team has different kinds of members with different roles: a manager, a small group of senior coders, and a group of helpers (hopefully ;p ).

Development Manager

The Development Manager shall oversee the Development Team and its three (3) sub-teams: IRCd, Services and Web. For the purpose of this document, we are only concerned with IRCd and Services.

The manager is the one responsible for keeping the integrity of the codebase. He or she (hereafter labeled "he" for brevity, not sexism) must be a experienced coder and know the internals of the server in detail.

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

The manager's decisions about actual coding matters take place with a "silent agreement" procedure.

Senior Coders

Senior coders are the most experienced and trusted coders that put the biggest effort into ircd-darenet and services-darenet development. They are the only other members of the team that have commit access to the svn repository. The manager is implicitly a senior coder.

Helpers

Everyone willing to contribute to the work of the team can be a helper simply by creating a dev.* account, and pariticipating on the forums.

Helpers do not have commit access to the svn repository, and they can't submit patches directly to the manager (if their are other senior coders on the team). Instead, they must follow the specific procedure described below to do it, in order to save some of the manager's time when checking in patches.

Tasks of the helpers include:

• Trying to help those who have trouble running or compiling the daemon and 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 find out if/how they can become realistic proposals for code changes.
• Working on the documentation of the code.

Procedures

Procedures for the tasks of the 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.

Categort:Staff Documentation