RulesForGitCommitters

Rules For Git Committers

This page is for people with direct Git commit access. (This is different from being able to submit a pull request. If you don't know whether you have access, you don't.)

We also have DeveloperGuidelines with general guidelines for development methodology.

Background

People depend on PortAudio. We don't hand out commit access lightly. New contributors are expected to submit patches for review. Once we trust you, and we think that there is utility in giving you commit access, then you may be offered commit access. Usually commit access is granted for a specific purpose, such as maintaining a particular module or host API. That said, if we trust you with commit access, we trust you to do the right thing by PortAudio and to help out wherever you can. Just follow the rules.

THE RULES

These are RULES. Rules help us all stay on the same page. Problems have occurred when the rules were not followed.

• Rule 0: communicate. The PortAudio Git repo is not your private playground. Before you commit something to Git make sure that you are confident that other committers would approve. When in doubt, communicate. Email the mailing list, or failing that, email Ross or Phil privately.

• PortAudio follows a trunk stable methodology. Don't check in untested code. Do your work in a Git branch and then submit a MergeRequest. Review contributed patches before merging them. Have someone else from the PA team review your code. GitHub has great code review tools, use them.

• PortAudio follows the module ownership principle. We like modules to have an owner, a default maintainer or a group of maintainers. No one is an expert in all native APIs, but the module maintainers have the best idea about their modules. They are most likely working on things behind the scenes. If you're not a maintainer, discuss changes with a module maintainer before making non-trivial changes to a module. Discussions on the mailing list are best. If you are unsure about who maintains a module, please ask (see below for a rough guide at the time of writing). Committing to a module does not bless you as exclusive maintainer of a module.

• Do not make a big new change and then disappear on holiday or project crunch. Be around on the mailing list to deal with potential fallout from your change.

• If you are the sole maintainer of a module then you have more scope to act freely. We will praise you for your great work. Keep in mind that with power comes great responsibility (and user bug reports.)

• Some modules don't have an owner, or the owner may be too busy to be useful. The above rules should not prevent obvious fixes from being checked in. Resolve these situations through discussion on the mailing list.

Rough guide to module ownership

Below is an overview of module maintainership/ownership. It was updated on 10 Sept, 2016. It could be out of date by the time that you read this. If anything is incorrect or missing please let us know. A reasonable way to keep track of this is to check who has been committing to a module lately.

src/common - Ross and Phil
src/os/unix - Alan, Bjorn, ???
src/os/win - Ross, Rob
src/hostapi/alsa - Alan
src/hostapi/asihpi - Eliot
src/hostapi/asio - Ross
src/hostapi/coreaudio - Bjorn, Phil, (Ross)
src/hostapi/dsound - Ross
src/hostapi/jack - ???
src/hostapi/oss - Alan
src/hostapi/skeleton - Ross
src/hostapi/wasapi - Dmitry
src/hostapi/wdmks - Rob
src/hostapi/wmme - Ross
test/ - none/everyone
qa/ - Phil
examples/ - none/everyone
./configure - no strict maintainer
Cmake scripts - Rob
static Visual Studio projects - David

Key:
 ??? means not sure
 Names in brackets have various meanings: Ross has done some work on hostapi/coreaudio; 
 hostapi/jack doesn't currently have an official maintainer.

Note:
 This list does not imply anything about module authorship. Most modules have had multiple contributors. 
 Many modules were developed by someone other than the current maintainer(s).