CommitRules

From Gnash Project Wiki

Jump to: navigation, search

These are the commonly agreed on policies for committers.

The rules are currently provisional and have not yet all been discussed and accepted.

  1. There is one set of policies for all committers.
  2. Formatting commits shall be committed separately from functional changes whenever possible.
  3. Commits shall not be reverted except as a last resort.
  4. Valid tests should never be dropped from the testsuite without discussion on the gnash-dev mailing list. A valid test is one that passes in the most recent Adobe Flashplayer under Windows.
  5. No code shall be committed that causes failures in existing tests. A failure is anything reported as an unexpected failure (FAIL) by the testsuite, and any crash even when not reported as a failure.
  6. Changing an expected pass to an expected fail is allowed only in exceptional cases, and should always be justified in the accompanying commit message.
  7. It is strongly recommended that a full set of build options (--enable-python --enable-cygnal --enable-extensions=all) be used when making changes so you don't break compiling for packages.
  8. Bugs that break builds should always be considered high-priority.
  9. Consider asking others (e.g., gnash-dev@) to review your changes before you commit them. This can save you a lot of headaches later, and is likely to increase the quality of the code. This can be worthwhile even for small changes.

We as developers should honour these policies as they make life easier for our fellow team members.

Handling Possible Violations

  1. All discussion should remain impersonal and civil at all times.
  2. Fix it yourself, or... (see discussion)
  3. If the developer is on #gnash on irc, mention something is broken, or email the gnash-commit@gnu.org, which all developers must be subscribed too.
  4. Allow a reasonable time frame for a response from the developer of the commit that broke builds or testing.
  5. If no response, #if 0/#endif an offending block of code to allow more response time.
  6. If still no response, initiate discussions about removing the block of offending code when possible, or reverting the changes.

Notes

A last resort means that a commit that breaks the other rules is not fixed or reverted by the committer in a reasonable time. Code reversion not done by the original committer should generally only be done by the maintainer after being proposed on the mailing list.

Using the Adobe player under other operating systems to validate tests is possible (and usual among Gnash developers). The Windows player merely serves as a reference if the results differ between platforms.

Running Gnash tests on more than one machine is highly recommended if this is possible.

An exceptional circumstance for changing a PASS to an XFAIL can be:

  • The test was bogus (see rule 4).
  • The test only passed before because something was not implemented
  • It's generally considered that the advantages of fixing other tests outweigh the cost of failing an old test. This should be discussed on the mailing list first!