Patching rules
- Always create a patch from the current tip of some branch.
- patch should be created starting from top directory of the dCache source tree apply-able with patch -p0 or patch -p1
- a patch should cleanly apply to specified branch and revision
- patch series have to be cleanly defined
- after applying a patch you should still be able to compile and produce packages
- 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)
- 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.
- code changes are not allowed with white space changes together
- no trailing whitespaces allowed in altered lines
- no leading tabs for .java, .xml files in altered lines
- [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
