wiki:SubmittingPatches
Last modified 6 years ago Last modified on 10/27/11 10:40:52

Patching rules

  1. Always create a patch from the current tip of some branch.
  2. patch should be created starting from top directory of the dCache source tree apply-able with patch -p0 or patch -p1
  3. a patch should cleanly apply to specified branch and revision
  4. patch series have to be cleanly defined
  5. after applying a patch you should still be able to compile and produce packages
  6. all existing unit test have to pass. It's allowed to add new unit tests which will fail

(Paul: insert usual hesitance about allowing failing tests here: the difference between 0 and 1 failures being much more prominent than n and n+1)

  1. For bug fixed a unit test or functional test should be provided that validates your change. The test should fail when run against a build without the change and succeed when run against a build with the change.
  2. code changes are not allowed with white space changes together
  3. no trailing whitespaces allowed in altered lines
  4. no leading tabs for .java, .xml files in altered lines

e-Mail

  • [PATCH #n/#total]: one-line summary
  • email body is used as a comment message ( for external contributors )
  • one patch per e-mail
  • no compression
  • no html
  • no base64 encoding
  • no attachments prefer
  • conforms to the commit message format.

review board

Review-Board is a prefered way to submit patches for review. Register yourself and submit the patch. Please use 'all' as reviewer group and '/' as base path for SVN based repository.

merge requests

if you want to merge to an older release-branch you have to send an email to support@… with a header starting with: [merge-req] (reviewboard-header)


Based on

/usr/src/linux/Documentation/SubmittingPatches

Netbeans Rules

OpenJDK rules