You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@xerces.apache.org by ne...@apache.org on 2002/03/27 23:09:29 UTC

cvs commit: xml-xerces/java/docs faq-contributing.xml docs-book.xml

neilg       02/03/27 14:09:29

  Modified:    java/docs docs-book.xml
  Added:       java/docs faq-contributing.xml
  Log:
  adding a FAQ for development-related issues.  Two entries supplied for starters:  one describing how to submit patches, the other how to prepare releases.
  
  Revision  Changes    Path
  1.14      +2 -1      xml-xerces/java/docs/docs-book.xml
  
  Index: docs-book.xml
  ===================================================================
  RCS file: /home/cvs/xml-xerces/java/docs/docs-book.xml,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- docs-book.xml	29 Jan 2002 18:33:53 -0000	1.13
  +++ docs-book.xml	27 Mar 2002 22:09:29 -0000	1.14
  @@ -1,7 +1,7 @@
   <?xml version='1.0' encoding='UTF-8'?>
   <!DOCTYPE book SYSTEM 'dtd/book.dtd'>
   <book title='&ParserName; Documentation' 
  -      copyright='1999-2001 The Apache Software Foundation'>
  +      copyright='1999-2002 The Apache Software Foundation'>
    <external label='Home' href='http://xml.apache.org/'/>
    <separator/>
    <document label='Readme' title='&ParserNameLong; Readme'
  @@ -45,6 +45,7 @@
          id='faq-write' source='faq-write.xml'/>
     <faq title='Performance FAQs' 
          id='faq-performance' source='faq-performance.xml'/>
  +  <faq title='FAQs for Developers and Prospective Contributors' id='faq-contributing' source='faq-contributing.xml'/>
    </faqs>
    <separator/>
    <settings title='Parser Features' label='Features' 
  
  
  
  1.1                  xml-xerces/java/docs/faq-contributing.xml
  
  Index: faq-contributing.xml
  ===================================================================
  <?xml version='1.0' encoding='UTF-8'?>
  <!DOCTYPE faqs SYSTEM 'dtd/faqs.dtd'>
  <faqs title='FAQs for Developers and Prospective Contributors'>
      <faq title="Submitting Patches">
      <q>I have a problem and I think I know how to fix it.  How can I
          communicate my ideas to the Xerces team?
      </q>
      <a>
          <p>To maximize the probability that your ideas will grab the
          attention of one of the Xerces developers who knows about the
          area of the parser you're concerned with, you should follow
          these steps:
      </p>
      <ol>
          <li>Check out and build the most recent Xerces code.  For
              instructions on how to do this, see <jump
              href="http://xml.apache.org/cvs.html">Apache XML Project CVS
              Information</jump>.  If you do this, you can confirm that your
              bug still exists and has not been fixed since the last
              release.
          </li>
          <li>
              Write up your bug report.  Include a description of your
              system (JDK level and vendor, platform and classpath
              contents) as well as sufficient code to reproduce the
              problem.  This code might involve XML documents,
              accompanying grammars, and the code you are using to
              invoke the parser or use its APIs.
          </li>
          <li>
              Describe why your solution works.
          </li>
          <li>
              Prepare a patch to fix Xerces code.  To do this, when you
              have applied your changes to a local copy of the most
              recent xerces source code, do <code>cvs diff -u
              file</code> for each file you&apos;ve changed.  
          </li>
          <li>
              Zip (or tar) up your patches.  If you send them in the
              body of a message or bug report they are very difficult to
              apply.
          </li>
          <li>
              Submit a bug report on <jump
              href="http://nagoya.apache.org/bugzilla">Bugzilla</jump>
              (remembering to attach your patches and test code)
              or, if you think your patch might need some discussion,
              post it to the xerces-j-dev list.
          </li>
      </ol>
      </a>
      </faq>
      <faq title="Release Preparation">
      <q>I am a recent committer.  It has fallen to my lot to prepare a Xerces-J
          release; how do I do this?
      </q>
      <a>
          <p>You're in luck--it isn&apos;t at all difficult.  Just
              follow these steps and you&apos;ll be done in no time:
          </p>
          <ol> 
          <li>Change the following files:<br/>
              <code>build.xml</code>
                  (that is, change the <code>parser.Version</code>,
                  <code>parser.version</code>, and 
                  <code>parser_version</code> properties as appropriate for the
                  release).<br/>  
              <code>docs/releases.xml</code> 
                  (contributors should have updated this file as significant 
                  changes/patches were applied, but the release manager should verify that 
                  nothing has slipped through.
                  Also, the release manager should attempt to ensure that appropriate
                  credit has been given for contributions).
          </li>
          <li>Tag the release in CVS
              (tags for releases usually have the form Xerces-J_x_y_z
              where x.y.z is the Xerces-J release number)
          </li>
          <li>Do a test build and regression test run;
              i.e., <code>build test</code> at a bare minimum.
              In general, apply as many test suites (Oasis XML
                  tests, W3C DOM and Schema tests etc.) as are
                  available, particularly with a view to preventing
                  regressions since the previous release.
          </li>
          <li>Do the final build based on that tag:<br/>
              windows build to produce <code>.zip</code>
                  packages<br/>
              unix build (on a unix machine to make sure no 0x0d's
                  appear in documentation of <code>.tar.gz</code>
                  packages.  Beware to do the build from within
                  X-windows to avoid problems with StyleBook on the
                  command-line!
          </li>
          <li>zip and tar the tools directory</li> 
          <li>
              Generate PGP/GNUPG signatures for dist binaries:<br/>
              That is, add public key to the CVS <code>KEYS</code> file if necessary
              and make sure public key is on a key server or two.
          </li>
          <li>Upload the binaries and signatures to the dist section of
              the website</li>
          <li>Update
              <code>/www/xml.apache.org/dist/xerces-j/.htaccess</code>, 
              which directs the user to the most recent release.  Take
              care to move old packages to the <code>old_xerces</code>
              directory so that the package listing is manageable.  
          </li>
          <li>Prepare release e-mail -- be sure to give contributors
              credit for their work</li>
          <li>Send the release e-mail to the xerces-j lists, general@xml and, if 
              it&apos;s a big enough release, announcements@xml.apache.org and 
              announcements@apache.org
          </li>
          <li>Bugzilla :<br/>
              Firstly, create new release.  Then,
              remove oldest release (if we are up-to 6
                  releases).
          </li>
          <li>Website:<br/>
              Upload generated docs directory to daedalus (until this process 
                  matures and becomes CVS-based).
              Commit <code>/www/xml.apache.org/xerces2-j</code> to CVS;
                 i.e., update the xml-site module.
          </li>
          </ol>
      </a>
      </faq>
  </faqs>
  
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-cvs-help@xml.apache.org