When will our bugs be fixed? When will our new features be added?

1. When will our bugs be fixed? When will our new features be added? When will the next release come out? Is my server up-to-date? Is this ready to release? What if the release is bad? When should we announce this? Users ReleaseManager Report Bugs Request New Features Responsible for final build Bugzilla Where can I get help?How can Will my Code be Accepted? I become a Committer? Mailing Lists What new features are essential? What does the community want? What is best for long term dev? What are other projects doing? Developers CVS Apache Website Submit Bug Fixes & Minor Features Contribute code for new Release Program Management Committee Review patches Documentation Testing Determine the Project Roadmap Oversight the Project Review and Vote on Patches Commit Patches to CVS Interact with the ASF Should I veto this? Promote Developers Mentor Developers Committers

2. User Concerns • Users can keep up to date by subscribing to the mailing list which will announce new releases and new patches • Developers will correspond with users via email when they are working on a bug they submitted or a new feature they requested

3. Report Bugs and Request New Features • Users report bugs and request new features through the Apache Bug database (Bugzilla). • Users should first install the most recent version of the HTTPD server and update all patches to ensure the bug has not already been fixed • Next they should search Bugzilla to see if it has already been reported or currently is being worked on • Finally, if it has not been fixed or reported they add their bug report or new feature report to Bugzilla

4. Developer Concerns • Developers can get help from • Committers who serve as mentors • Mailing list • Guidelines on the project website • Developers are dependent on Committers to accept or reject their patch and then release it

5. Submission of Work • Code and Documentation is submitted and voted upon for release • For patches, committers follow a commit-then-review policy (commit and revoke if anyone objects to it later) • For new features as well as planned release’s feature, committers follow a review-then-commit policy (must be unanimously approved by everyone before being committed)

6. Review Patches • Developers can review patches and vote on them • However only committers votes count (i.e. the binding votes) • A developer’s vote is also considered as binding if and only if he or she is the patch owner • Otherwise, the vote is just a standing opinion

7. Documentation • Documentation is treated just like source code • Submitted into the CVS only by committers • Developer contributes new content as patches • Documentation patches are then voted on by committers

8. Testing • Developers mainly participate in Alpha and Beta Testing • Testing version of software is distributed in a different branch of the source code repository then the released version of the code • Only developers or high ‘level’ can access this • Final Testing (i.e. advance to G.A.) is performed on the Apache Software Foundation web server, hosting the website for at least 3 days before public announcement is issued

9. Committers Concerns • How to determine the quality of the patches? • Commit-then-review? • Review-then-commit? • Vetoes?

10. Patches • Currently, patches are treated with the commit-then-review policy • Hence, it is only governed by the lacy consensus

11. Promote and Mentor Developers • Ongoing advising and monitoring the quality of code contribution by developers • Acknowledge developer’s consistent high-quality contribution by recommending promotion of status • Must be unanimously agreed among all committers

12. PMC Concerns • What are the interests of the general community (i.e. users)? • Interact with other project communities (e.g. Mozilla, Jarkata, NetBeans, etc.) • What is are the interests of the project community (i.e. developers, committers, etc)? • Extract information from discussion in conference (e.g. Apachecon) and mailing list (e.g. developers) • Where to gather milestones for the next release • From Bugzilla, find PRs with a “enhancement” severity

13. Project Goals and Community Oversight • Make sure the project’s progress is align with the ‘STATUS’ file • Keep the interaction among committers on-going • Resolve any conflicts within the community • Ensure community standard is maintained and in active

14. Interaction with ASF • Discussion the project direction with • the Board of Directors • Foundation Members of ASF • Align the project direction with the business goals • Bring up any possible issues encountered (e.g. licensing issues?)

15. Release Manager Concerns • Which release ‘style’ should I employ? • “quick-and-efficient”: building the source and tagging it as distribution, before a thorough testing • “slow-but-reliable”: building the source without tagging as distribution, and wait for a thorough testing • What is the appropriate time to release? • Follow the guideline from the ‘STATUS’ file • Interaction with PMC

16. Releasing the Final Build • Responsible for all 3 stages • Alpha • ? • Beta • After vigorous testing from Alpha • Will be run on web server hosting the http://www.apache.org/ for at least 3 days, before advancing to GA stage • General Availability (GA) • Announcement is sent to mailing list • In each stage, do the build-tag-tarball-announce