docs/project/committer_guide.pod - Committer Guide.
From docs/project/roles_responsibilities.pod:
Contributors who submit numerous, high-quality patches may be considered to become a Committer. Committers have commit access to the full Parrot repository, but generally work only on one or more subprojects; Committer categories are described below. Contributors may considered for commit access either by being nominated by another Committer, or by asking for it.
To add a new file to Parrot, in your git working copy use the command:
% git add <filename>
Be sure to update the MANIFEST when you've added new files. You do this by running:
% perl tools/dev/mk_manifest_and_skip.pl
Files generated by Parrot at build time should get ignored such that Cgit status> doesn't pick them up. They also need to get added to MANIFEST.SKIP so that Parrot's configuration mechanism doesn't complain about extra files. You can tell git to ignore files by adding them to .gitignore.
Your Parrot working copy must make successfully before committing your changes to the repository.
It would be best practice to run make test and make sure that your change hasn't broken anything before committing. However, as make test takes a long time, it is recommended to run at least make codetest. This target runs only the file metadata and the basic coding standards tests.
In case you want to check the POD of your changed file, you can run perl t/codingstd/pod_syntax.t path/to/my/file .
Each text file needs to have near its beginning the line (or equivalent depending upon the current language's comment character):
# Copyright (C) <creation_year>-<current_year>, Parrot Foundation.
To remove a file from the Parrot source, you need to use the git rm command:
% git rm <filename>
Removing files is much the same as adding files in that you need to run tools/dev/mk_manifest_and_skip.pl to create the MANIFEST and MANIFEST.SKIP files appropriately. Also, you should check that you've not broken anything by running make test before committing the removal to the repository.
Our recommended workflow for git is documented in docs/project/git_workflow.pod.
docs/project/roles_responsibilities.pod, RESPONSIBLE_PARTIES
