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>


Be sure to update the MANIFEST when you've added new files. You do this by running:

  % perl tools/dev/

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/doc/pod.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.

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/ 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.


docs/project/roles_responsibilities.pod, RESPONSIBLE_PARTIES