Apache HTTPD Project A user-driven development –Quality should override everything else Meritocracy –The more work you have done, the more you are allowed to do –You have to prove yourself in the group

Level of involvement Core group of committers (the PMC of Apache?) –“Business” issues and limited-circulation things Committers –People with ‘write’ access to repository Developers Users

Developer  Committer? Nominated by a current active member Unanimously approved by the voting members In most cases, this ‘new’ member has been actively contributing to the group for over six months

Developer’s checklist Coding Style Guide – Debugging Guide – Bug Database Policies – Apache Development Note –

Guideline and Roadmap Guideline Extremely out-of-date version The current version 2.0/ROADMAP?rev=1.7&content- type=text/vnd.viewcvs-markup 2.0/ROADMAP?rev=1.7&content- type=text/vnd.viewcvs-markup

Voting Many issues are resolved by voting –Code change, feature proposal, etc Kind of vote: –+1: yes –-1: no, or vetoes – +/- 0: no opinion Ideas must be review-then-commit (RTC); patches can be commit-then-review (CTR).

Approval Process Consensus – for features? –Must receive at least 3 binding +1 votes and no vetos Majority – for other thing, such as style? –Must receive at least 3 binding +1 votes and more +1 votes than -1 votes Lazy – for patches? –No minimal requirement. No special discussion will be carried out until someone votes -1

Vetoes Vetoes must be accompanied by a convincing explanation Vetoes cannot be overwritten; vetoer must be the one who withdraw the vote In progress by Apache HTTPD Group –Under what conditions a veto can be rescinded or overridden?

How do they track problems? Apache Bug Report Database People not only use this tool to track problems (using PRs), but also use this tool to post occasional suggestion/fix. State transition of PRs –Open  Analyzed  Feedback  Closed? –Suspended?

Patches A way to communicate proposed changes ( output of a unified "diff -u oldfile newfile" command ) Official patch Unofficial patch (Contributory)

How do they track changes? Change log Categories –PR resolved by committers (majority) Name listed on –PR resolved by developers –Enhancements/Features added by developers

Changes related to PRs Fix suexec behavior with user directories. PR [Colm ] Fix PidFile to default to rel_runtimedir instead of rel_logfiledir. PR [Andreas Hasenack ] Properly substitute sbindir as httpd's location in apachectl. PR [Andreas Hasenack ]

Fix perchild MPM so that it uses ap_gname2id for groups instead of ap_uname2id. [Scott Lamb ] Change mod_status to use scoreboard accessor functions so it can be used in any MPM without having to be recompiled. [Ryan Morgan ] add optional fixup hook to proxy [Daniel Lopez ] Changes unrelated to PRs

The “STATUS” file Keep track of the agenda and plans for work –action items, proposed changes, tracking votes, brief note about developer’s task, release plans, etc Automatically posted to the mailing list each week.

Apache HTTPD 2.0 series 2.0/STATUS?rev=1.621&conten- type=text/vnd.viewcvs-markup 2.0/STATUS?rev=1.621&conten- type=text/vnd.viewcvs-markup Apache HTTPD 1.3 series 1.3/STATUS?rev=1.987&content- type=text/vnd.viewcvs-markup 1.3/STATUS?rev=1.987&content- type=text/vnd.viewcvs-markup

The ‘patch-vote-release’ process Patch coordinator –Maintain and circulate the list of proposed patches Vote coordinator –Announce a voting period, then tally the votes for each patch Release manager –Apply the approved patches to the latest release

Testing/Stages? Alpha? Beta? GA?

Other projects FreeBSD NetBSD -process.html -process.html OpenPKG Mozilla process/release.html