head	1.7;
access;
symbols
	TIGRIS_1_1_0RC2:1.5
	TIGRIS_1_1_0RC1:1.5
	TIGRIS_1_1:1.5.0.4
	TIGRIS_1_0_8:1.5
	TIGRIS_1_0_8RC3:1.5
	TIGRIS_1_0_8RC2:1.5
	TIGRIS_1_0_8RC1:1.5
	TIGRIS_1_0_7:1.5
	TIGRIS_1_0_7RC3:1.5
	TIGRIS_1_0_7RC2:1.5
	TIGRIS_1_0_7RC1:1.5
	TIGRIS_1_0_6:1.5
	TIGRIS_1_0_6RC5:1.5
	TIGRIS_1_0_6RC4:1.5
	TIGRIS_1_0_6RC3:1.5
	TIGRIS_1_0_6RC2:1.5
	TIGRIS_1_0_6RC1:1.5
	TIGRIS_1_0_5:1.5
	TIGRIS_1_0_5RC6:1.5
	TIGRIS_1_0_5RC5:1.5
	TIGRIS_1_0_5RC4:1.5
	TIGRIS_1_0_5RC3:1.5
	TIGRIS_1_0_5RC2:1.5
	TIGRIS_1_0_5RC1:1.5
	TIGRIS_1_0_4:1.5
	TIGRIS_1_0_3:1.5
	TIGRIS_1_0_2:1.5
	TIGRIS_1_0_1:1.5
	TIGRIS_1_0:1.5.0.6
	TIGRIS_1_0_0:1.5
	TIGRIS_1_0_0_RC1:1.5.0.2
	dlr:1.1.1
	TIGRIS_0_9_2_4:1.1
	TIGRIS_0_9_2_3:1.1
	HELM_PEER_PORT_BRANCH:1.1.1.1
	TURBINE_PEER:1.1
	TIGRIS_0_9_2_1:1.1
	TIGRIS_0_9_2:1.1.0.6
	TIGRIS_0_8_4:1.1.0.4
	TIGRIS_0_9_0:1.1.0.2;
locks; strict;
comment	@# @;


1.7
date	2001.06.21.07.07.40;	author jefflove;	state Exp;
branches;
next	1.6;

1.6
date	2001.06.11.03.14.33;	author jefflove;	state Exp;
branches;
next	1.5;

1.5
date	2001.03.16.23.50.35;	author lori;	state Exp;
branches;
next	1.4;

1.4
date	2001.02.11.18.29.47;	author jrobbins;	state Exp;
branches;
next	1.3;

1.3
date	2001.02.09.00.59.20;	author susank;	state Exp;
branches;
next	1.2;

1.2
date	2001.02.05.16.44.20;	author lori;	state Exp;
branches;
next	1.1;

1.1
date	2000.12.30.23.22.01;	author jrobbins;	state Exp;
branches
	1.1.1.1
	1.1.4.1
	1.1.8.1;
next	;

1.1.1.1
date	2001.02.21.00.32.02;	author dlr;	state Exp;
branches;
next	;

1.1.4.1
date	2001.01.16.00.17.44;	author susank;	state Exp;
branches;
next	;

1.1.8.1
date	2001.02.17.18.39.16;	author edk;	state Exp;
branches;
next	;


desc
@@


1.7
log
@html usage revision
@
text
@  <div class="docs" id="contributingpatches">
   <h2>Contributing Patches</h2>

   <div class="toc">
    <h3>Additional resources about issues: Index</h3>

    <ul>
     <li>
      <a href="ProjectIssues.html">Project Issues help</a> 

      <ul>
       <li><a href="issue_lifecycle.html">The issue life cycle</a></li>

       <li><a href="issuewritinghelp.html">Issue writing guidelines</a></li>

       <li><a href="issuezilla_tipsandtricks.html">IssueZilla tips and tricks</a></li>

       <li><strong>You are here:</strong> Contributing patches</li>
      </ul>
     </li>
    </ul>
   </div>

   <div class="courtesylinks">
    <p><a href="/servlets/HelpTOC">Back to main Help index</a></p>
   </div>

   <p>Well-described, easy-to-apply patches are a pleasure for other developers to encounter and go a long way towards making the module or component more stable and powerful.</p>

   <p><strong>If you are not yet a member of an open source project</strong> on this site but you have mailing list access, you can post a message about your proposed patch to the project's developer mailing list. (Read more about <a href="Subscribing.html">subscribing to project mailing lists</a>.)</p>

   <p><strong>If you are a project member</strong>, first conduct a query of the project's issue database to determine whether this patch is associated with an already reported defect.</p>

   <p>If your patch pertains to an existing issue, you should use the <strong>File Attach</strong> field in the issue edit screen to submit your patch and the <strong>Add Comment</strong> section to post an explanatory message. (Remember that changes to issues generate automatic email messages to the issue's owner and anyone on the cc list. All of those people will receive your message and a link to your patch.)</p>

   <p>If an issue <i>does not exist</i>, submit your patch as a new issue, using the <i>Patch</i> link in the "Enter An Issue" section of the <b>Project Issues</b> page. Attach your patch file to the new issue. Here's how to do it:</p>

   <ol>
    <li>
     <p>First, make sure you are making changes in the most recent version of the source files -- for this, it is best to use CVS to check out the source (on the CVS trunk), make your modifications (but do not check them in), and then run the command:</p>

     <p><code>cvs diff -c &gt; mypatch</code></p>

     <p>... to get a context-format patch for the sources. This gives you a patch file which includes information about the version you are patching, the filenames, and the contents of the change. This is the preferred way to keep track of patches and makes it easier for others to find and test your patch.</p>
    </li>

    <li>
     <p>To apply a patch, go to the proper directory and run:</p>

     <p><code>patch &lt; issuepatch.diff</code></p>
    </li>

    <li>
     <p>Always include a message with your patch with the following information:</p>

     <ul>
      <li>A description of what problem or defect you are attempting to fix, and the steps to reproduce it, if possible.</li>

      <li>A description of what the behavior should be with the patch in place.</li>

      <li>A description of how the patch works, if reasonable. If a significant amount of code is involved, include within the message that you agree to let the patch be used under the applicable project license as part of the IDE's code.</li>
     </ul>
    </li>
   </ol>

   <p>The developer responsible for the section of code affected should either apply the patch and mark the defect (if there is one registered) as fixed, or reply with an objection if it does not seem safe, does not appear to fix the problem, or there is not really a problem to begin with. Notifications of any changes to the issues database, as well as CVS check-ins, are automatically sent to the appropriate issue assignee/cc'd and CVS mailing lists, so you can monitor whether the patch has been applied. Be sure to subscribe to at least the CVS and issue mailing lists for the module you are working on.</p>

   <p>If you do not know exactly how to fix a problem, but have an idea about what is causing it, you can post a message about this on the developer discussion list for other project members' suggestions or to find someone who knows how to fix it.</p>

   <div class="courtesylinks">
    <p><a href="ProjectIssues.html">Back to Project Issues help</a><br />
     <a href="/servlets/HelpTOC">Back to main Help index</a></p>
   </div>
  </div>
 


@


1.6
log
@extensive markup rework - first pass toward house xhtmlification
@
text
@d1 2
a2 6
<!DOCTYPE html PUBLIC "-//CollabNet//DTD XHTML 1.0 Transitional//EN"
"http://collabnet.com/dtds/collabnet_transitional_10.dtd">
<html>
 <head>
  <title>Contributing Patches</title>
 </head>
d4 2
a5 3
 <body>
  <div class="docs" id="contributingpatches">
<h2>Contributing Patches</h2>
d7 3
a9 1
  <p><strong>Additional resources about issues: Index</strong></p>
d11 2
a12 2
   <dl>
    <dt><a href="ProjectIssues.html">Project Issues help</a></dt>
d14 1
a14 1
    <dd><a href="issue_lifecycle.html">The issue life cycle</a></dd>
d16 1
a16 1
    <dd><a href="issuewritinghelp.html">Issue writing guidelines</a></dd>
d18 5
a22 1
    <dd><a href="issuezilla_tipsandtricks.html">IssueZilla tips and tricks</a></dd>
d24 3
a26 1
    <dd><strong>You are here: Contributing patches</strong></dd>
d28 1
a28 2
    <dt><a href="/servlets/HelpTOC">Back to main Help index</a></dt>
   </dl>  
d30 1
a30 1
  <p>Well-described, easy-to-apply patches are a pleasure for other developers to encounter and go a long way towards making the module or component more stable and powerful.</p>
d32 1
a32 1
  <p><strong>If you are not yet a member of an open source project</strong> on this site but you have mailing list access, you can post a message about your proposed patch to the project's developer mailing list. (Read more about <a href="Subscribing.html">subscribing to project mailing lists</a>.)</p>
d34 1
a34 1
  <p><strong>If you are a project member</strong>, first conduct a query of the project's issue database to determine whether this patch is associated with an already reported defect.</p>
d36 1
a36 1
  <p>If your patch pertains to an existing issue, you should use the <strong>File Attach</strong> field in the issue edit screen to submit your patch and the <strong>Add Comment</strong> section to post an explanatory message. (Remember that changes to issues generate automatic email messages to the issue's owner and anyone on the cc list. All of those people will receive your message and a link to your patch.)</p>
d38 3
a40 1
  <p>If an issue <i>does not exist</i>, submit your patch as a new issue, using the <i>Patch</i> link in the "Enter An Issue" section of the <b>Project Issues</b> page. Attach your patch file to the new issue. Here's how to do it:</p>
d42 1
a42 6
  <ol>
   <li>
   <p>
 First, make sure you are making changes in the most recent version of the source files -- for this, it is best to use CVS to check out the source (on the CVS trunk), make your modifications (but do not check them in), and then run the command:
</p>
     
d44 2
a45 1
    <p><strong>cvs diff -c &gt; mypatch</strong></p>
d47 2
a48 2
    <p>... to get a context-format patch for the sources. This gives you a patch file which includes information about the version you are patching, the filenames, and the contents of the change. This is the preferred way to keep track of patches and makes it easier for others to find and test your patch.</p>
   </li>
d50 2
a51 4
   <li>
<p>
    To apply a patch, go to the proper directory and run: 
</p>
d53 2
a54 2
    <p><strong>patch &lt; issuepatch.diff</strong></p>
   </li>
d56 2
a57 4
   <li>
<p>
    Always include a message with your patch with the following information: 
</p>
d59 1
a59 2
    <ul>
     <li>A description of what problem or defect you are attempting to fix, and the steps to reproduce it, if possible.</li>
d61 4
a64 1
     <li>A description of what the behavior should be with the patch in place.</li>
d66 1
a66 4
     <li>A description of how the patch works, if reasonable. If a significant amount of code is involved, include within the message that you agree to let the patch be used under the applicable project license as part of the IDE's code.</li>
    </ul>
   </li>
  </ol>
d68 1
a68 1
  <p>The developer responsible for the section of code affected should either apply the patch and mark the defect (if there is one registered) as fixed, or reply with an objection if it does not seem safe, does not appear to fix the problem, or there is not really a problem to begin with. Notifications of any changes to the issues database, as well as CVS check-ins, are automatically sent to the appropriate issue assignee/cc'd and CVS mailing lists, so you can monitor whether the patch has been applied. Be sure to subscribe to at least the CVS and issue mailing lists for the module you are working on.</p>
d70 6
a75 7
  <p>If you do not know exactly how to fix a problem, but have an idea about what is causing it, you can post a message about this on the developer discussion list for other project members' suggestions or to find someone who knows how to fix it.</p>
  <div class="courtesylinks">
  <a href="ProjectIssues.html">Back to Project Issues help</a><br />
<a href="/servlets/HelpTOC">Back to main Help index</a>
</div> </div>
</body>
</html>
@


1.5
log
@added index
@
text
@d1 2
d4 3
a6 1
<head>
d8 3
a10 1
<title>Contributing Patches</title>
d12 1
a12 2
</head>
<body>
d14 37
a50 1
    <span class="Header" nowrap>Contributing Patches</span>
d52 7
a58 33
    <span class="PlainText"><strong>Additional resources about issues: Index</strong>
<ul>
	<dl>
	<dt><a href="ProjectIssues.html">Project Issues help</a>
		<dd><a href="issue_lifecycle.html">The issue life cycle</a> 
		<dd><a href="issuewritinghelp.html">Issue writing guidelines</a>
		<dd><a href="issuezilla_tipsandtricks.html"> IssueZilla tips and tricks</a>
		<dd><strong>You are here: Contributing patches</strong>
	<dt><a href="/servlets/HelpTOC">Back to main Help index</a>
	</dl>
</ul>

<hr noshade size=1>
     <p>

Well-described, easy-to-apply patches are a pleasure for other developers to encounter and go a long way towards making the module or component more stable and powerful.

     <p><span class=plaintextbold>If you are not yet a member of an open source project</span> on this site but you have mailing list access, you can post a message about your proposed patch to the project's developer mailing list. (Read more about <a href="Subscribing.html">subscribing to project mailing lists</a>.)</p>

     <p><span class=plaintextbold>If you are a project member</span>, first conduct a query of the project's issue database to determine whether this patch is associated with an already reported defect. 

     <p>If your patch pertains to an existing issue, you should use the <span class=plaintextbold>File Attach</span> field in the issue edit screen to submit your patch and the <span class=plaintextbold>Add Comment</span> section to post an explanatory message. (Remember that changes to issues generate automatic email messages to the issue's owner and anyone on the cc list. All of those people will receive your message and a link to your patch.)
     <p>If an issue <i>does not exist</i>, submit your patch as a new issue, using the <i>Patch</i> link in the "Enter An Issue" section of the <b>Project Issues</b> page. Attach your patch file to the new issue. Here's how to do it:</p>
     <ol>    
  <li>First, make sure you are making changes in the most recent version of the source files -- for this, it is best to use CVS to check out the source (on the CVS trunk), make your modifications (but do not check them in), and then run the command: </p>
<p>
<span class=plaintextbold>cvs diff -c > mypatch</span>
<p>
... to get a context-format patch for the sources. This gives you a patch file which includes information about the version you are patching, the filenames, and the contents of the change. This is the preferred way to keep track of patches and makes it easier for others to find and test your patch.
     <p>
<li>To apply a patch, go to the proper directory and run: 
<p>
<span class=plaintextbold>patch &lt; issuepatch.diff</span>
d60 2
d63 2
a64 3
<li>Always include a message with your patch with the following information:
<p>
     <ul>
d66 1
a66 9
      <li>A description of what problem or defect you are attempting to fix, and the steps to reproduce it, if possible.
<p>
      <li>A description of what the behavior should be with the patch in place. 
<p>
      <li>A description of how the patch works, if reasonable. If a significant amount of code is involved, include within the message that you agree to let the patch be used under the applicable project license as part of the IDE's code.
     </ul>
</ol>
<span class=plaintext>
     <p>The developer responsible for the section of code affected should either apply the patch and mark the defect (if there is one registered) as fixed, or reply with an objection if it does not seem safe, does not appear to fix the problem, or there is not really a problem to begin with. Notifications of any changes to the issues database, as well as CVS check-ins, are automatically sent to the appropriate issue assignee/cc'd and CVS mailing lists, so you can monitor whether the patch has been applied. Be sure to subscribe to at least the CVS and issue mailing lists for the module you are working on.</p>
d68 4
a71 1
     <p>If you do not know exactly how to fix a problem, but have an idea about what is causing it, you can post a message about this on the developer discussion list for other project members' suggestions or to find someone who knows how to fix it.</p>
d73 1
d75 3
a77 2
<hr noshade size=1>
<a href="ProjectIssues.html">Back to Project Issues help</a><br>
d79 1
a79 2
    </span>
 
d82 2
@


1.4
log
@added <title> tags to all files
@
text
@d1 2
a2 2
<HTML>
<HEAD>
d4 4
a7 1
<TITLE>Contributing Patches</TITLE>
a8 4
</HEAD>
<BODY>
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
d10 29
a38 15
  
    <span class="PlainText"> 
     <P>Well-described, easy-to-apply patches are a pleasure for other developers to encounter and go a long way towards making the module or component more stable and powerful.

     <P><SPAN class=PlainTextBold>If you are not yet a member of an open source project</SPAN> on this site but you have mailing list access, you can post a message about your proposed patch to the project's developer mailing list. (Read more about <A HREF="Subscribing.html">subscribing to project mailing lists</A>.)</P>

     <P><SPAN class=PlainTextBold>If you are a project member</SPAN>, first conduct a query of the project's issue database to determine whether this patch is associated with an already reported defect. 

     <P>If your patch pertains to an existing issue, you should use the <SPAN class=PlainTextBold>File Attach</SPAN> field in the issue edit screen to submit your patch and the <SPAN class=PlainTextBold>Add Comment</SPAN> section to post an explanatory message. (Remember that changes to issues generate automatic email messages to the issue's owner and anyone on the cc list. All of those people will receive your message and a link to your patch.)
     <P>If an issue <I>does not exist</I>, submit your patch as a new issue, using the <I>Patch</I> link in the "Enter An Issue" section of the <B>Project Issues</B> page. Attach your patch file to the new issue. Here's how to do it:</P>
     <OL>    
  <LI>First, make sure you are making changes in the most recent version of the source files -- for this, it is best to use CVS to check out the source (on the CVS trunk), make your modifications (but do not check them in), and then run the command: </P>
<P>
<span class=PlainTextBold>cvs diff -c > mypatch</SPAN>
<P>
d40 30
a69 33
     <P>
<LI>To apply a patch, go to the proper directory and run: 
<P>
<span class=PlainTextBold>patch &lt; issuepatch.diff</span>
<P>

<LI>Always include a message with your patch with the following information:
<P>
     <UL>

      <LI>A description of what problem or defect you are attempting to fix, and the steps to reproduce it, if possible.
<P>
      <LI>A description of what the behavior should be with the patch in place. 
<P>
      <LI>A description of how the patch works, if reasonable. If a significant amount of code is involved, include within the message that you agree to let the patch be used under the applicable project license as part of the IDE's code.
     </UL>
</OL>
<span class=PlainText>
     <P>The developer responsible for the section of code affected should either apply the patch and mark the defect (if there is one registered) as fixed, or reply with an objection if it does not seem safe, does not appear to fix the problem, or there is not really a problem to begin with. Notifications of any changes to the issues database, as well as CVS check-ins, are automatically sent to the appropriate issue assignee/cc'd and CVS mailing lists, so you can monitor whether the patch has been applied. Be sure to subscribe to at least the CVS and issue mailing lists for the module you are working on.</P>

     <P>If you do not know exactly how to fix a problem, but have an idea about what is causing it, you can post a message about this on the developer discussion list for other project members' suggestions or to find someone who knows how to fix it.</P>


<HR NOSHADE SIZE=1>
<A HREF="ProjectIssues.html">Back to Project Issues help</A><BR>
<A HREF="/servlets/HelpTOC">Back to main Help index</A>
    </SPAN>
  </TR>
</TABLE>


</BODY>
</HTML>
@


1.3
log
@removed window's nasty line breaks, and corrected more links in HelpBox files
PR:
Obtained from:
Submitted by:
Reviewed by:
@
text
@d1 7
d58 2
@


1.2
log
@updated for new help format
@
text
@d1 50
a50 50
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
    <span class="Header" nowrap>Contributing Patches</span>
  
    <span class="PlainText"> 
     <P>Well-described, easy-to-apply patches are a pleasure for other developers to encounter and go a long way towards making the module or component more stable and powerful.

     <P><SPAN class=PlainTextBold>If you are not yet a member of an open source project</SPAN> on this site but you have mailing list access, you can post a message about your proposed patch to the project's developer mailing list. (Read more about <A HREF="Subscribing.html">subscribing to project mailing lists</A>.)</P>

     <P><SPAN class=PlainTextBold>If you are a project member</SPAN>, first conduct a query of the project's issue database to determine whether this patch is associated with an already reported defect. 

     <P>If your patch pertains to an existing issue, you should use the <SPAN class=PlainTextBold>File Attach</SPAN> field in the issue edit screen to submit your patch and the <SPAN class=PlainTextBold>Add Comment</SPAN> section to post an explanatory message. (Remember that changes to issues generate automatic email messages to the issue's owner and anyone on the cc list. All of those people will receive your message and a link to your patch.)
     <P>If an issue <I>does not exist</I>, submit your patch as a new issue, using the <I>Patch</I> link in the "Enter An Issue" section of the <B>Project Issues</B> page. Attach your patch file to the new issue. Here's how to do it:</P>
     <OL>    
  <LI>First, make sure you are making changes in the most recent version of the source files -- for this, it is best to use CVS to check out the source (on the CVS trunk), make your modifications (but do not check them in), and then run the command: </P>
<P>
<span class=PlainTextBold>cvs diff -c > mypatch</SPAN>
<P>
... to get a context-format patch for the sources. This gives you a patch file which includes information about the version you are patching, the filenames, and the contents of the change. This is the preferred way to keep track of patches and makes it easier for others to find and test your patch.
     <P>
<LI>To apply a patch, go to the proper directory and run: 
<P>
<span class=PlainTextBold>patch &lt; issuepatch.diff</span>
<P>

<LI>Always include a message with your patch with the following information:
<P>
     <UL>

      <LI>A description of what problem or defect you are attempting to fix, and the steps to reproduce it, if possible.
<P>
      <LI>A description of what the behavior should be with the patch in place. 
<P>
      <LI>A description of how the patch works, if reasonable. If a significant amount of code is involved, include within the message that you agree to let the patch be used under the applicable project license as part of the IDE's code.
     </UL>
</OL>
<span class=PlainText>
     <P>The developer responsible for the section of code affected should either apply the patch and mark the defect (if there is one registered) as fixed, or reply with an objection if it does not seem safe, does not appear to fix the problem, or there is not really a problem to begin with. Notifications of any changes to the issues database, as well as CVS check-ins, are automatically sent to the appropriate issue assignee/cc'd and CVS mailing lists, so you can monitor whether the patch has been applied. Be sure to subscribe to at least the CVS and issue mailing lists for the module you are working on.</P>

     <P>If you do not know exactly how to fix a problem, but have an idea about what is causing it, you can post a message about this on the developer discussion list for other project members' suggestions or to find someone who knows how to fix it.</P>


<HR NOSHADE SIZE=1>
<A HREF="ProjectIssues.html">Back to Project Issues help</A><BR>
<A HREF="/servlets/HelpTOC">Back to main Help index</A>
    </SPAN>
  </TR>
</TABLE>


@


1.1
log
@moved core documentation into helm, fewer overrides need to be in instances now
@
text
@d1 50
a50 95
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
    <TD class="Header" nowrap>Contributing Patches</TD>
  </TR>
</TABLE>
<TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2" BORDER="0" width="100%">
  <TR>
    <TD class="PlainText" VALIGN="top"> 

     <P>Well-described, easy-to-apply patches are a pleasure for other
     developers to encounter and go a long way towards making the
     module or component IDE more stable and powerful.

     <P><SPAN class=PlainTextBold><I>If you are not yet a member of
     the project</I></SPAN> but you have mailing list access, you can
     post a message to the project's developer mailing list. (Read
     more about <A
     HREF="/project/www/docs/DomainDocsMailingLists.html">mailing
     lists</A>.)</P>

     <P><SPAN class=PlainTextBold><I>If you are a project
     member</I></SPAN>, first conduct a query of the project's
     IssueZilla database to determine whether this patch is associated
     with an already reported defect.

     <P>If an issue <I>exists</I>, you should use the <SPAN
     class=PlainTextBold>File Attach</SPAN> field in IssueZilla to
     submit your patch and the <SPAN class=PlainTextBold>Add
     Comment</SPAN> section to post an explanatory message. (Remember
     that changes to issues generate automatic email messages to the
     issue's owner and anyone on the cc list. All of those people will
     receive your message and a link to your patch.)

     <P>If an issue <I>does not exist</I>, submit your patch as a new
     issue, using the <SPAN class=PlainTextBold>File Attach</SPAN> to
     include your patch file. Here's how to do it:</P>

     <UL>    

      <LI>First, make sure you are making changes in the most recent
      version of the sources -- for this, it is best to use CVS to
      check out the source (on the CVS trunk), make your modifications
      (but do not check them in), and then run the command: </P>
      <P>
      <span class="TypewriterBold">cvs diff -c > mypatch</SPAN>
      <P>
      ... to get a context-format patch for the sources. This gives
      you a patch file which includes information about the version
      you are patching, the filenames, and the contents of the
      change. This is the preferred way to keep track of patches and
      makes it easier for others to find and test your patch.
<P>
     <LI>To apply a patch, go to the proper directory and run: 
     <P>
     <span class="TypewriterBold">patch &lt; issuepatch.diff</span>
    <P>

<LI>Always include a message with your patch with the following information:
<P>
     <UL>

      <LI>A description of what problem or defect you are attempting
      to fix, and the steps to reproduce it, if possible.

      <LI>A description of what the behavior should be with the patch
      in place.

      <LI>A description of how the patch works, if reasonable. If a
      significant amount of code is involved, include within the
      message that you agree to let the patch be used under the
      applicable project license as part of the IDE's code.
     </UL>
   </UL>

     <P>The developer responsible for the section of code affected
     should either apply the patch and mark the defect (if there is
     one registered) as fixed, or reply with an objection if it does
     not seem safe, does not appear to fix the problem, or there is
     not really a problem to begin with. Notifications of any changes
     to the issues database, as well as CVS check-ins, are
     automatically sent to the appropriate issue assignee/cc'd and CVS
     mailing lists, so you can monitor whether the patch has been
     applied. Be sure to subscribe to at least the CVS and issue
     mailing lists for the module you are working on.</P>

     <P>If you do not know exactly how to fix a problem, but have an
     idea about what is causing it, you can post a message about this
     on the developer discussion list for other project members'
     suggestions or to find someone who knows how to fix it.</P>

    </TD>
  </TR>
</TABLE>


@


1.1.1.1
log
@Replacing the HEAD with the HELM_PEER_PORT_BRANCH.
@
text
@a0 7
<HTML>
<HEAD>

<TITLE>Contributing Patches</TITLE>

</HEAD>
<BODY>
d3 49
a51 15
    <span class="Header" nowrap>Contributing Patches</span>
  
    <span class="PlainText"> 
     <P>Well-described, easy-to-apply patches are a pleasure for other developers to encounter and go a long way towards making the module or component more stable and powerful.

     <P><SPAN class=PlainTextBold>If you are not yet a member of an open source project</SPAN> on this site but you have mailing list access, you can post a message about your proposed patch to the project's developer mailing list. (Read more about <A HREF="Subscribing.html">subscribing to project mailing lists</A>.)</P>

     <P><SPAN class=PlainTextBold>If you are a project member</SPAN>, first conduct a query of the project's issue database to determine whether this patch is associated with an already reported defect. 

     <P>If your patch pertains to an existing issue, you should use the <SPAN class=PlainTextBold>File Attach</SPAN> field in the issue edit screen to submit your patch and the <SPAN class=PlainTextBold>Add Comment</SPAN> section to post an explanatory message. (Remember that changes to issues generate automatic email messages to the issue's owner and anyone on the cc list. All of those people will receive your message and a link to your patch.)
     <P>If an issue <I>does not exist</I>, submit your patch as a new issue, using the <I>Patch</I> link in the "Enter An Issue" section of the <B>Project Issues</B> page. Attach your patch file to the new issue. Here's how to do it:</P>
     <OL>    
  <LI>First, make sure you are making changes in the most recent version of the source files -- for this, it is best to use CVS to check out the source (on the CVS trunk), make your modifications (but do not check them in), and then run the command: </P>
<P>
<span class=PlainTextBold>cvs diff -c > mypatch</SPAN>
d53 1
a53 1
... to get a context-format patch for the sources. This gives you a patch file which includes information about the version you are patching, the filenames, and the contents of the change. This is the preferred way to keep track of patches and makes it easier for others to find and test your patch.
d55 2
a56 4
<LI>To apply a patch, go to the proper directory and run: 
<P>
<span class=PlainTextBold>patch &lt; issuepatch.diff</span>
<P>
d62 10
a71 5
      <LI>A description of what problem or defect you are attempting to fix, and the steps to reproduce it, if possible.
<P>
      <LI>A description of what the behavior should be with the patch in place. 
<P>
      <LI>A description of how the patch works, if reasonable. If a significant amount of code is involved, include within the message that you agree to let the patch be used under the applicable project license as part of the IDE's code.
d73 1
a73 5
</OL>
<span class=PlainText>
     <P>The developer responsible for the section of code affected should either apply the patch and mark the defect (if there is one registered) as fixed, or reply with an objection if it does not seem safe, does not appear to fix the problem, or there is not really a problem to begin with. Notifications of any changes to the issues database, as well as CVS check-ins, are automatically sent to the appropriate issue assignee/cc'd and CVS mailing lists, so you can monitor whether the patch has been applied. Be sure to subscribe to at least the CVS and issue mailing lists for the module you are working on.</P>

     <P>If you do not know exactly how to fix a problem, but have an idea about what is causing it, you can post a message about this on the developer discussion list for other project members' suggestions or to find someone who knows how to fix it.</P>
d75 15
d91 1
a91 4
<HR NOSHADE SIZE=1>
<A HREF="ProjectIssues.html">Back to Project Issues help</A><BR>
<A HREF="/servlets/HelpTOC">Back to main Help index</A>
    </SPAN>
a95 2
</BODY>
</HTML>
@


1.1.8.1
log
@porting changes from the head to the branch
@
text
@a0 7
<HTML>
<HEAD>

<TITLE>Contributing Patches</TITLE>

</HEAD>
<BODY>
d3 49
a51 15
    <span class="Header" nowrap>Contributing Patches</span>
  
    <span class="PlainText"> 
     <P>Well-described, easy-to-apply patches are a pleasure for other developers to encounter and go a long way towards making the module or component more stable and powerful.

     <P><SPAN class=PlainTextBold>If you are not yet a member of an open source project</SPAN> on this site but you have mailing list access, you can post a message about your proposed patch to the project's developer mailing list. (Read more about <A HREF="Subscribing.html">subscribing to project mailing lists</A>.)</P>

     <P><SPAN class=PlainTextBold>If you are a project member</SPAN>, first conduct a query of the project's issue database to determine whether this patch is associated with an already reported defect. 

     <P>If your patch pertains to an existing issue, you should use the <SPAN class=PlainTextBold>File Attach</SPAN> field in the issue edit screen to submit your patch and the <SPAN class=PlainTextBold>Add Comment</SPAN> section to post an explanatory message. (Remember that changes to issues generate automatic email messages to the issue's owner and anyone on the cc list. All of those people will receive your message and a link to your patch.)
     <P>If an issue <I>does not exist</I>, submit your patch as a new issue, using the <I>Patch</I> link in the "Enter An Issue" section of the <B>Project Issues</B> page. Attach your patch file to the new issue. Here's how to do it:</P>
     <OL>    
  <LI>First, make sure you are making changes in the most recent version of the source files -- for this, it is best to use CVS to check out the source (on the CVS trunk), make your modifications (but do not check them in), and then run the command: </P>
<P>
<span class=PlainTextBold>cvs diff -c > mypatch</SPAN>
d53 1
a53 1
... to get a context-format patch for the sources. This gives you a patch file which includes information about the version you are patching, the filenames, and the contents of the change. This is the preferred way to keep track of patches and makes it easier for others to find and test your patch.
d55 2
a56 4
<LI>To apply a patch, go to the proper directory and run: 
<P>
<span class=PlainTextBold>patch &lt; issuepatch.diff</span>
<P>
d62 10
a71 5
      <LI>A description of what problem or defect you are attempting to fix, and the steps to reproduce it, if possible.
<P>
      <LI>A description of what the behavior should be with the patch in place. 
<P>
      <LI>A description of how the patch works, if reasonable. If a significant amount of code is involved, include within the message that you agree to let the patch be used under the applicable project license as part of the IDE's code.
d73 1
a73 5
</OL>
<span class=PlainText>
     <P>The developer responsible for the section of code affected should either apply the patch and mark the defect (if there is one registered) as fixed, or reply with an objection if it does not seem safe, does not appear to fix the problem, or there is not really a problem to begin with. Notifications of any changes to the issues database, as well as CVS check-ins, are automatically sent to the appropriate issue assignee/cc'd and CVS mailing lists, so you can monitor whether the patch has been applied. Be sure to subscribe to at least the CVS and issue mailing lists for the module you are working on.</P>

     <P>If you do not know exactly how to fix a problem, but have an idea about what is causing it, you can post a message about this on the developer discussion list for other project members' suggestions or to find someone who knows how to fix it.</P>
d75 15
d91 1
a91 4
<HR NOSHADE SIZE=1>
<A HREF="ProjectIssues.html">Back to Project Issues help</A><BR>
<A HREF="/servlets/HelpTOC">Back to main Help index</A>
    </SPAN>
a95 2
</BODY>
</HTML>
@


1.1.4.1
log
@adding the generic, default docs into this branch, bc they are in the head and nec for instantiations using stable branches
@
text
@@

