Thu May 6 02:26:19 2004
Apache AxKit Mission Statement and Project Guidelines (Draft)
AxKit Mission Statement Apache AxKit is project of the Apache Software Foundation, charged with the task of developing and maintaining an Open Source, modular, pipeline-based Web application and publishing environment built upon the Apache HTTP Server, the Perl and C programming languages, and standard and/or popular XML processing technologies. Our goal is to provide an scalable, stable, and flexible framework within which users are free to choose among a series of off-the-shelf components provided by the Apache AxKit Project Community to meet common publishing and application requirements, while ensuring that special needs are easily addressable though the use of user-defined components. We agree, both in principle and practice, with the ideals of the Apache Software Foundation as expressed in the informal list of six principles known colloquially as The Apache Way. Specifically: * Collaborative software development * Commercial-friendly standard license * Consistently high quality software * Respectful, honest, technical-based interaction * Faithful implementation of standards * Security as a mandatory feature AxKit Project Guidelines This section defines the guidelines for the Apache AxKit Project. It includes definitions of how conflict is resolved by voting, who is able to vote, and the procedures to follow for proposing and making changes to the AxKit product. The objective here is to avoid unnecessary conflict over changes and continue to produce a quality system in a timely manner. Not all conflict can be avoided, but at least we can agree on the procedures for conflict to be resolved. Useful Definitions AxKit Project Management Committee (PMC) The group of volunteers who are responsible for managing the AxKit Project. This includes deciding what is distributed as products of the AxKit Project, maintaining the Project's shared resources, speaking on behalf of the Project, resolving license disputes regarding AxKit products, nominating new PMC members or committers, and establishing these guidelines. Membership in the AxKit PMC is by invitation only and must be approved by consensus of the active AxKit PMC members. A PMC member is considered inactive by their own declaration or by not contributing in any form to the project for over six months. An inactive member can become active again by reversing whichever condition made them inactive (i.e., by reversing their earlier declaration or by once again contributing toward the project's work). Membership can be revoked by a unanimous vote of all the active PMC members other than the member in question. AxKit Committers The group of volunteers who are responsible for the technical aspects of the AxKit Project. This group has write access to the appropriate source repositories and these volunteers may cast binding votes on any technical discussion. Membership as a Committer is by invitation only and must be approved by consensus of the active AxKit PMC members. A Committer is considered inactive by their own declaration or by not contributing in any form to the project for over six months. An inactive member can become active again by reversing whichever condition made them inactive (i.e., by reversing their earlier declaration or by once again contributing toward the project's work). Membership can be revoked by a unanimous vote of all the active PMC members (except the member in question if they are a PMC member). AxKit Developers All of the volunteers who are contributing time, code, documentation, or resources to the AxKit Project. A developer that makes sustained, welcome contributions to the project for over six months is usually invited to become a Committer, though the exact timing of such invitations depends on many factors. AxKit Project Release Manager (Pumpking) An AxKit Committer charged with the co-ordination of the release and maintenance of a single major subversion release of the AxKit Project and each of its micro-versions (1.70 through 1.7x, for example). The Release Manager (RM) is selected based on the consensus approval among active committers of a proposed release plan. This plan then becomes the roadmap for the next development cycle and its author becomes the RM responsible for that subversion. Release Plan Drawn from a combination of discussions on the developer's mailing list and open items in the current product's STATUS file, a release plan defines the goals and projected time lines for a given subversion release of AxKit, as well as each of its mirco-versions. Public Mailing List The AxKit developers' primary mailing list for discussion of issues and changes related to the project (axkit-dev@xml.apache.org). Subscription to the list is open, but only subscribers can post directly to the list. Private Mailing List The AxKit Group's private mailing list for discussion of issues that are inappropriate for public discussion, such as legal, personal, or security issues prior to a published fix. Subscription to the list is only open to AxKit Group members (Committers). CVS All of the AxKit products are maintained in shared information repositories using CVS on cvs.apache.org. Only some of the AxKit developers have write access to these repositories; everyone has read access via anonymous CVS. Developers who want write access need to ask for it on the mailing list and, if approved, need to ask the admin of cvs.apache.org for a user account. This, in effect, makes that developer an AxKit Committer. The STATUS File Each of the AxKit Project's active source code repositories contain a file called "STATUS" which is used to keep track of the agenda and plans for work within that repository. The STATUS file includes information about release plans, a summary of code changes committed since the last release, a list of proposed changes that are under discussion, brief notes about items that individual developers are working on or want discussion about, and anything else that might be useful to help the group track progress. The active STATUS files are automatically posted to the mailing list each week. Many issues will be encountered by the project, each resulting in zero or more proposed action items. Issues should be raised on the mailing list as soon as they are identified. Action items must be raised on the mailing list and added to the relevant STATUS file. All action items may be voted on, but not all of them will require a formal vote. STATUS Action Items Long Term Plans Long term plans are simply announcements that group members are working on particular issues related to the AxKit software. These are not voted on, but group members who do not agree with a particular plan, or think an alternate plan would be better, are obligated to inform the group of their feelings. In general, it is always better to hear about alternate plans prior to spending time on less adequate solutions. Short Term Plans Short term plans are announcements that a developer is working on a particular set of documentation or code files, with the implication that other developers should avoid them or try to coordinate their changes. This is a good way to proactively avoid conflict and possible duplication of work. Release Plan A release plan is used to keep all the developers aware of when a release is desired, who will be the release manager, when the repository will be frozen in order to create the release, and assorted other trivia to keep us from tripping over ourselves during the final moments. Lazy majority decides each issue in the release plan. Release Testing After a new release is built, colloquially termed a tarball, it must be tested before being released to the public. Majority approval is required before the tarball can be publicly released. Showstoppers Showstoppers are issues that require a fix be in place before the next public release. They are listed in the STATUS file in order to focus special attention on the problem. An issue becomes a showstopper when it is listed as such in STATUS and remains so by lazy consensus. Product Changes Changes to the AxKit product, including code and documentation, will appear as action items under several categories corresponding to the change status: concept/plan An idea or plan for a change. These are usually only listed in STATUS when the change is substantial, significantly impacts the API, or is likely to be controversial. Votes are being requested early so as to uncover conflicts before too much work is done. proposed patch A specific set of changes to the current product in the form of input to the patch command (a diff output). committed change A one-line summary of a change that has been committed to the repository since the last public release. All product changes to the currently active repository are subject to lazy consensus. All product changes to a prior-branch (old version) repository require consensus before the change is committed. Voting Any of the AxKit Developers may vote on any issue or action item. However, the only binding votes are those cast by active members of the AxKit Group; if the vote is about a change to source code or documentation, the primary author of what is being changed may also cast a binding vote on that issue. All other votes are non-binding. All developers are encouraged to participate in decisions, but the decision itself is made by those who have been long-time contributors to the project. In other words, the AxKit Project is a minimum-threshold meritocracy. The act of voting carries certain obligations -- voting members are not only stating their opinion, they are agreeing to help do the work of the AxKit Project. Since we are all volunteers, members often become inactive for periods of time in order to take care of their "real jobs" or devote more time to other projects. It is therefore unlikely that the entire group membership will vote on every issue. To account for this, all voting decisions are based on a minimum quorum of 50% of the active AxKit Group membership. Each vote can be made in one of three flavors: +1 Yes, agree, or the action should be performed. On some issues, this vote is only binding if the voter has tested the action on their own system(s). ±0 Abstain, no opinion, or I am happy to let the other group members decide this issue. An abstention may have detrimental effects if too many people abstain. -1 No. On issues where consensus is required, this vote counts as a veto. All vetos must include an explanation of why the veto is appropriate. A veto with no explanation is void. No veto can be overruled. If you disagree with the veto, you should lobby the person who cast the veto. Voters intending to veto an action item should make their opinions known to the group immediately, so that the problem can be remedied as early as possible. An action item requiring consensus approval must receive at least 3 binding +1 votes and no vetos. An action item requiring majority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes (i.e., a majority with a minimum quorum of three positive votes). All other action items are considered to have lazy approval until someone votes -1, after which point they are decided by either consensus or a majority vote, depending upon the type of action item. Votes are tallied within the STATUS file, adjacent to the action item under vote. All votes must be either sent to the mailing list or added directly to the STATUS file entry for that action item. When To Commit Changes All changes to the currently active repository will be made on commit-then-review (CTR) basis. With a commit-then-review process, we trust that the developer doing the commit has a high degree of confidence in the change. Doubtful changes, new features, and large-scale overhauls need to be discussed before being committed to a repository. Any change that affects the semantics of arguments to configurable directives, significantly adds to the runtime size of the program, or changes the semantics of an existing API function must receive consensus approval on the mailing list before being committed. Each developer is responsible for notifying the mailing list and adding an action item to STATUS when they have an idea for a new feature or major change to propose for the product. The distributed nature of the Apache AxKit project requires an advance notice of 48 hours in order to properly review a major change -- consensus approval of either the concept or a specific patch is required before the change can be committed. Note that a member might veto the concept (with an adequate explanation), but later rescind that veto if a specific patch satisfies their objections. No advance notice is required to commit singular bug fixes. Related changes should be committed as a group, or very closely together. Half-completed projects should not be committed unless doing so is necessary to pass the baton to another developer who has agreed to complete the project in short order. All code changes must be successfully compiled on the developer's platform before being committed. The current source code tree should be capable of complete compilation at all times. However, it is sometimes impossible for a developer on one platform to avoid breaking some other platform when a change is committed, particularly when completing the change requires access to a special development tool on that other platform. If it is anticipated that a given change will break some other platform, the committer must indicate that in the commit log. The committer is responsible for the quality of any third-party code or documentation they commit to the repository. All software committed to the repository must be covered by the Apache LICENSE or contain a copyright and license that allows redistribution under the same conditions as the Apache LICENSE. A committed change must be reversed if it is vetoed by one of the voting members and the veto conditions cannot be immediately satisfied by the equivalent of a "bug fix" commit. The veto must be rescinded before the change can be included in any public release. Patch Format When a specific change to the software is proposed for discussion or voting on the mailing list, it should be presented in the form of input to the patch command. When sent to the mailing list, the message should contain a Subject beginning with PATCH and a distinctive one-line summary corresponding to the action item for that patch. Afterwards, the patch summary in the STATUS file should be updated to point to the Message-ID of that message. The patch should be created by using the diff -u command from the original software file(s) to the modified software file(s). E.g., diff -u http_main.c.orig http_main.c >> patchfile.txt or cvs diff main_http.c >> patchfile.txt All patches necessary to address an action item should be concatenated within a single patch message. If later modification of the patch proves necessary, the entire new patch should be posted and not just the difference between two patches. The STATUS file entry should then be updated to point to the new patch message. The completed patchfile should produce no errors or prompts when the command, is issued in the target repository. Addenda and Errata All URLs and email addresses reflect the current resources available to AxKit as part of the XML PMC and will need to be changed. Edit This Page / Show Page History / |
 |
Home