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.
Adding new files
To add a new file to Parrot, in your git working copy use the command:
% git add <filename>
MANIFEST
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
Ignored files
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.
Tests before committing; make codetest
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
.
License
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.
Removing files
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.
Working with Git
Our recommended workflow for git is documented in docs/project/git_workflow.pod.
SEE ALSO
docs/project/roles_responsibilities.pod, RESPONSIBLE_PARTIES