This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

PATCH for: Development Plan for Future Releases

On Mon, 16 Jul 2001, Mark Mitchell wrote:
> The Steering Committee has, after much deliberation, and after
> considering the various opinions presented on the public mailing
> lists, adopted the proposal detailed below.

And here is the updated for the web page. (I had prepared this but
unfortunately didn't manage to tweak and commit before now.)



Index: index.html
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.256
diff -u -3 -p -r1.256 index.html
--- index.html	2001/07/17 16:10:01	1.256
+++ index.html	2001/07/18 09:54:09
@@ -153,6 +153,14 @@ scheduled for early August</a>.

+<dt><b>July 17, 2001</b></dt>
+The <a href="steering.html">Steering Committee</a> adopted a
+<a href="develop.html">new development plan</a> which we will
+start using for GCC 3.1, scheduled for April 15, 2002.
 <dt><b>July 9, 2001</b></dt>
 Daniel Berlin and Jeff Law have contributed a
--- /dev/null	Wed Jul 18 09:17:36 2001
+++ develop.html	Wed Jul 18 11:50:16 2001
@@ -0,0 +1,227 @@
+<title>GCC Development Plan</title>
+<h1 align="center">GCC Development Plan</h1>
+<p>The goals of this policy are:</p>
+<li>Higher-quality releases</li>
+<li>Support for more targets</li>
+<li>Continued encouragement of major infrastructure improvements</li>
+<li>More predictable release schedules</li>
+<li>More frequent releases</li>
+<p>It has been difficult for us to make consistent, high-quality
+releases that support a wide variety of targets.  In particular, GCC
+3.0 achieved a high standard of quality on many targets, but was by no
+means perfect, and failed to support as many targets as we would have
+<p>In addition, the release was late relative to original scheduling
+estimates.  And, the time between the GCC 2.95 and GCC 3.0 releases
+was longer than everyone would have liked.  We think that we will
+better serve the user community by making releases somewhat more
+frequently, and on a consistent schedule.</p>
+<p>In addition, a consistent schedule will make it possible for the
+Release Manager to better understand his or her time commitment will
+be when he or she agrees to take the job.</p>
+<h2>Development Methodology</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>
+<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>
+<p>There is no firm guideline for what constitutes a "major change"
+and what does not.  If a developer is unsure, 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 branch only after:</p>
+<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 use a simulator for
+validation; the use of real hardware is not required.</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
+<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>
+<p>Development on our main branch will proceed in three stages.  Each
+stage will be two months in length.</p>
+<h4>Stage 1</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>Stage 2</h4>
+<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 added in a front-end, or support
+for a new variant of an existing microprocessor might be added to a
+<h4>Stage 3</h4>
+<p>During this period, the only changes that may be made to the
+compiler are changes that fix bugs.  New functionality may not be
+introduced during this period.</p>
+<p>In order to produce releases on a regular schedule, we must ensure
+that the mainline is reasonably stable some time before we make the
+release.  Therefore, more radical changes must be made earlier in the
+cycle, so that we have time to fix any problems that result.</p>
+<p>In order to reach higher standards of quality, we must focus on
+fixing bugs; by working exclusively on bug-fixing through Stage 3, we
+will have a higher quality source base as we prepare for a release.</p>
+<p>Although maintaining a branch, including merging new changes from
+the mainline, is somewhat burdensome, the absolute worst case is that
+such a branch will have to be maintained for four months.  During two
+of those months, the only mainline changes will be bug-fixes, 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
+<p>After the patch has been reverted, the poster may appeal the
+decision to the Steering Committee.</p>
+<p>If an important platform is broken, then it will be difficult to
+prepare a release.  If nobody volunteers to fix the problem, then we
+will have an unpleasant choice: delay the release, or release a
+compiler that we know to be worse than the previous release.
+Therefore, it is important that we be able to revert patches that
+cause problems.  In addition, regressions on the mainline can impede
+the development of other improvements.</p>
+<p>On the other hand, we want to encourage new development, and new
+development inevitable introduces new bugs.  Therefore, it is
+important that decisions be made on a case-by-case basis, and that the
+proponent of a change have an opportunity to argue that the benefits
+of the change outweigh the costs.  Therefore, the decision to revert
+requires two consenting parties, and such decisions may be appealed to
+the Steering Committee.  However, during the appeal, the mainline will
+remain working, to avoid impeding other development.</p>
+<h2>Release Methodology</h2>
+<p>At the conclusion of Stage 3 above, a release branch will be
+<p>On the release branch, the focus will be fixing any regressions
+from the previous release, so that each release is better than the one
+<p>The release will occur two months after the creation of the branch.
+(Stage 1 of the next release cycle will occur in parallel.)  If,
+however, support for an important platform has regressed significantly
+from the previous release or support for a platform with active
+maintenance has regressed significantly relative to an earlier Stage
+in the current release cycle, the release will be postponed until the
+regressions are corrected, unless the Steering Committee releases the
+automatic hold on the release.</p>
+<p>While making releases on schedule is important, quality should not
+be subordinate to schedule.  If a major platform is not adequately
+supported, but was well supported in a previous release, then we
+should address the problems.  Presumably, this will not be unduly
+difficult, since we will have spent four months fixing bugs by the
+time the release would occur.</p>
+<h3>Bug-fix Releases</h3>
+<p>Bug-fix releases will be made two and four months after the initial
+release, as necessary.</p>
+<p>By waiting for two months to make a bug-fix release, we will be
+able to accumulate fixes for the most important problems, and avoid
+spending undue amounts of time on release testing and packaging.</p>
+<p id="1">Note that no distinction is made between patches which are
+themselves buggy and patches which expose "latent" bugs elsewhere in
+the compiler.</p>
+<p id="2">The Steering Committee is planning to prepare a list of such
+targets.  The list will be revised at the beginning of each release
+cycle, if necessary.</p>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]