JDS Rules

The following rules apply for hacking on the JDS sources -

• All patches that are not branding or vendor specific configuration MUST be submitted upstream to the original community of the component.
• Patches that are rejected by the upstream community are considered broken and should be reworked where possible. Each patch that remains locally increases the maintenance burden for any future work with that component.
• FIXIT@THESOURCE: Find the root cause of the problem and either fix it yourself, or collaborate to get it fixed. You should not apply a workaround if at all possible. Temporary workarounds are appropriate in some cases, although not something that should be done long term.
• Patches should be applied within the Linux spec files and MUST work on both Linux and Solaris.
• Avoid using %ifos
• If a patch requires images or other binary files, put those in ext-sources. Remember to use the -kb CVS option when adding binaries. Where possible other files should be merged into a patch.
• Update %changelog in the spec file for ALL non-trivial changes and make sure you have a ChangeLog entry to accompany this. There is a ChangeLog in the top level directory, and a ChangeLog in the Solaris directory. Use them as appropriate.
• The commit log message should be the same as what is in the ChangeLog entry. When you go to commit, do not use the -m CVS option, instead wait for the prompt, and cut and paste your ChangeLog entry in it.
• Follow the spec file templates -

  docs/template.spec

  Linux spec file template

  docs/SUNWtemplate.spec

  Solaris spec file template

• Avoid patching patches.