[wwwdocs] Make develop.html more readable

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

Again, I think this just looks better and more friendly.

XHTML validated, OK?

Gr.
Steven

Index: develop.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.33
diff -c -3 -p -r1.33 develop.html
*** develop.html	11 Jun 2003 22:38:53 -0000	1.33
--- develop.html	1 Aug 2003 14:02:03 -0000
***************
*** 7,15 ****
  
  <h1>GCC Development Plan</h1>
  
! <h2>Objectives</h2>
  
! <p>The goals of this policy are:</p>
  
  <ol>
  <li>Higher-quality releases</li>
--- 7,37 ----
  
  <h1>GCC Development Plan</h1>
  
! <p>GCC is one of the largest Free Software projects, driven by a relatively
! incoherent group of contributors with sometimes very different goals.  To
! make sure that the mission and goals of the GCC project itself are met,
! it is necessary to document the development plan employed by the GCC
! community.  This page describes the common goals and the development plan
! for the project.</p>
! 
! <p>Typically, suggestions for changes to this plan are discussed on the
! <a href="mailto:gcc@gcc.gnu.org";>GCC mailing list</a> and approved or
! rejected by the <a href="steering.html">GCC Steering Committee</a>.</p>
  
! <ul>
! <li><a href="#objectives">Objectives</a></li>
! <li><a href="#developmentcycle">Development Cycle</a></li>
! <li><a href="#patchreversion">Patch Reversion</a></li>
! <li><a href="#majorchanges">Major Changes</a></li>
! <li><a href="#releasemethodology">Release Methodology</a></li>
! <li><a href="#future">Release Calendar</a></li>
! </ul>
! 
! <hr />
! 
! <h2><a name="objectives">Objectives</a></h2>
! 
! <p>The goals of the development plan oulined here are:</p>
  
  <ol>
  <li>Higher-quality releases</li>
*************** Release Manager to better understand his
*** 38,111 ****
  be when he or she agrees to take the job.</p>
  
  
! <h2>Development Methodology</h2>
! 
! 
! <h3>Branches</h3>
! 
! <p>The development of major changes shall be done on a branch.  (Under
! some circumstances, development may be done in a private development
! tree, but the Steering Committee strongly encourages the use of a
! branch in the publicly accessible GCC development tree.)</p>
! 
! <p>Examples of major changes include:</p>
! 
! <ul>
! <li>A new C++ parser</li>
! <li>A new memory allocation scheme for internal use in the compiler</li>
! <li>A new optimization pass</li>
! </ul>
! 
! <p>There is no firm guideline for what constitutes a "major change"
! and what does not.  If a developer is unsure, he or she should ask for
! guidance on the GCC mailing lists.  In general, a change that has the
! potential to be extremely destabilizing should be done on a branch.</p>
! 
! <p>Changes may be merged from a development branch only after:</p>
! 
! <ul>
! <li>They meet the standards for any other check-in.  For example, the
! code must be well-documented, and any user-visible changes, including
! command-line options, should be documented in the manual.</li>
! 
! <li>The branch has been validated on three different targets, each
! targeting a different microprocessor family.  Validation should
! consist of bootstrapping the compiler (unless that is impossible for
! the microprocessor selected) and checking that there are no new
! regression test failures.  It is acceptable to <a
! href="simtest-howto.html">use a simulator</a> for
! validation; the use of real hardware is not required.</li>
! </ul>
! 
! <p><strong>Rationale</strong></p>
! 
! <p>Making major improvements to the compiler is good.  However, such
! changes are inevitably somewhat destabilizing.  By using a branch, it
! is possible for people to test and improve the code, but without
! impacting other developers.  By testing major changes more thoroughly
! than ordinary changes, we will help reduce the impact on other
! developers.</p>
! 
! <p>In addition, the presence of half-finished projects on the mainline
! presents a variety of problems when preparing for a release.  If
! serious bugs remain, it may be impossible to do a release until the
! bugs are fixed, thereby impacting the release schedule.  If
! functionality is present, but not robust (for example, command-line
! options that activate an optimization pass that does not work very
! well), then we can seriously confuse users.</p>
! 
! 
! <h3>Schedule</h3>
  
! <p>Development on our main branch will proceed in three stages.  Each
! stage will be two months in length.</p>
  
! <h4><a name="stage1">Stage 1</a></h4>
  
  <p>During this period, changes of any nature may be made to the
! compiler.  In particular, major changes may be merged from branches.</p>
  
! <h4><a name="stage2">Stage 2</a></h4>
  
  <p>During this period, major changes may not be merged from branches.
  However, other smaller improvements may be made.  For example, support
--- 60,78 ----
  be when he or she agrees to take the job.</p>
  
  
! <h2><a name="developmentcycle">Development Cycle</a></h2>
  
! <p>Development on our main branch (usually refered to as the <em>mainline</em>
! or the <em>trunk</em>) will proceed in three stages.  Each stage will be two
! months in length.</p>
  
! <h3><a name="stage1">Stage 1</a></h3>
  
  <p>During this period, changes of any nature may be made to the
! compiler.  In particular, <a href="majorchanges">major changes</a>
! may be merged from branches.</p>
  
! <h3><a name="stage2">Stage 2</a></h3>
  
  <p>During this period, major changes may not be merged from branches.
  However, other smaller improvements may be made.  For example, support
*************** for a new language construct might be ad
*** 113,119 ****
  for a new variant of an existing microprocessor might be added to a
  back-end.</p>
  
! <h4><a name="stage3">Stage 3</a></h4>
  
  <p>During this period, the only (non-documentation) changes that may be
  made are changes that fix bugs.  New functionality may not be introduced
--- 80,86 ----
  for a new variant of an existing microprocessor might be added to a
  back-end.</p>
  
! <h3><a name="stage3">Stage 3</a></h3>
  
  <p>During this period, the only (non-documentation) changes that may be
  made are changes that fix bugs.  New functionality may not be introduced
*************** During two of those months, the only mai
*** 137,153 ****
  so it is unlikely that many conflicts will occur.</p>
  
  
! <h3>Patch Reversion</h3>
  
! <p>If a patch is committed which introduces a regression <a
! href="#1">[1]</a>, on any target which the Steering Committee
! considers to be important <a href="#2">[2]</a>, and the problem is
! reported to the original poster, and 48 hours pass without either the
! original poster or any other party indicating that a fix will be
! forthcoming in the very near future, and two people with write
! privileges to the affected area of the compiler determine that the
! best course of action is to revert the patch, then they may revert the
! patch.</p>
  
  <p>After the patch has been reverted, the poster may appeal the
  decision to the Steering Committee.</p>
--- 104,125 ----
  so it is unlikely that many conflicts will occur.</p>
  
  
! <h2><a name="patchreversion">Patch Reversion</a></h2>
  
! <p>It sometimes can happen that a patch is committed to the mainline, but
! it introduces a regression <a href="#1">[1]</a>.  To prevent unnecessary
! slowdown in the normal development cycle, the patch may be reverted if
! all of the following conditions are met:</p>
! 
! <ul>
! <li>the problem is reported to the original poster;</li>
! <li>48 hours pass without either the original poster or any other party
!     indicating that a fix will be forthcoming in the very near future;</li>
! <li>the Steering Committee considers the affected target to be important
!     <a href="#2">[2]</a>;</li>
! <li>two people with write privileges to the affected area of the compiler
!     determine that the best course of action is to revert the patch.</li>
! </ul>
  
  <p>After the patch has been reverted, the poster may appeal the
  decision to the Steering Committee.</p>
*************** the Steering Committee.  However, during
*** 172,178 ****
  remain working, to avoid impeding other development.</p>
  
  
! <h2>Release Methodology</h2>
  
  
  <h3>Schedule</h3>
--- 144,205 ----
  remain working, to avoid impeding other development.</p>
  
  
! <h2><a name="majorchanges">Major Changes</a></h2>
! 
! <p>The development of major changes shall be done on a branch.  (Under
! some circumstances, development may be done in a private development
! tree, but the Steering Committee strongly encourages the use of a
! branch in the publicly accessible GCC development tree.)</p>
! 
! <p>Examples of major changes include:</p>
! 
! <ul>
! <li>A new C++ parser</li>
! <li>A new memory allocation scheme for internal use in the compiler</li>
! <li>A new optimization pass</li>
! </ul>
! 
! <p>There is no firm guideline for what constitutes a "major change"
! and what does not.  If a developer is unsure, he or she should ask for
! guidance on the GCC mailing lists.  In general, a change that has the
! potential to be extremely destabilizing should be done on a branch.</p>
! 
! <p>Changes may be merged from a development branch only after:</p>
! 
! <ul>
! <li>They meet the standards for any other check-in.  For example, the
! code must be well-documented, and any user-visible changes, including
! command-line options, should be documented in the manual.</li>
! 
! <li>The branch has been validated on three different targets, each
! targeting a different microprocessor family.  Validation should
! consist of bootstrapping the compiler (unless that is impossible for
! the microprocessor selected) and checking that there are no new
! regression test failures.  It is acceptable to <a
! href="simtest-howto.html">use a simulator</a> for
! validation; the use of real hardware is not required.</li>
! </ul>
! 
! <p><strong>Rationale</strong></p>
! 
! <p>Making major improvements to the compiler is good.  However, such
! changes are inevitably somewhat destabilizing.  By using a branch, it
! is possible for people to test and improve the code, but without
! impacting other developers.  By testing major changes more thoroughly
! than ordinary changes, we will help reduce the impact on other
! developers.</p>
! 
! <p>In addition, the presence of half-finished projects on the mainline
! presents a variety of problems when preparing for a release.  If
! serious bugs remain, it may be impossible to do a release until the
! bugs are fixed, thereby impacting the release schedule.  If
! functionality is present, but not robust (for example, command-line
! options that activate an optimization pass that does not work very
! well), then we can seriously confuse users.</p>
! 
! 
! 
! <h2><a name="releasemethodology">Release Methodology</a></h2>
  
  
  <h3>Schedule</h3>
*************** able to accumulate fixes for the most im
*** 214,220 ****
  spending undue amounts of time on release testing and packaging.</p>
  
  
! <h3><a name="future">Calendar</a></h3>
  
  <p>Here is a history of recent and a <em>tentative</em> timeline of upcoming
  stages of development, branch points, and releases:</p>
--- 241,247 ----
  spending undue amounts of time on release testing and packaging.</p>
  
  
! <h2><a name="future">Release Calendar</a></h2>
  
  <p>Here is a history of recent and a <em>tentative</em> timeline of upcoming
  stages of development, branch points, and releases:</p>