<h2>JDS Rules</h2>
<style>
li {padding:3px;}
</style>
<p>
The following rules apply for hacking on the JDS sources -
<p>
<ul>
<li>
All patches that are not branding or vendor specific configuration
<b>MUST</b> be submitted upstream to the original community of the
component.
</li>
<li>
Patches that are rejected by the upstream community are considered
<b>broken</b> and should be reworked where possible. Each patch
that remains locally increases the maintenance burden for any
future work with that component.
</li>
<li>
<b>FIXIT@THESOURCE</b>: 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.
</li>
<li>
Patches should be applied within the Linux spec files and <b>MUST</b>
work on <b>both</b> Linux and Solaris.
</li>
<li>
Avoid using <b>%ifos</b>
</li>
<li>
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.
</li>
<li>
Update %changelog in the spec file for <b>ALL</b> 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.
</li>
<li>
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.
</li>
<li>
Follow the spec file templates -
<blockquote>
<dl>
<dd>Linux spec file template</dd>
<dd>Solaris spec file template</dd>
</dl>
</blockquote>
</li>
<li>
Avoid patching patches.
</li>
</ul>