* Important: Development Plan for Future Releases
@ 2001-07-16 21:03 Mark Mitchell
2001-07-17 0:51 ` Joseph S. Myers
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Mark Mitchell @ 2001-07-16 21:03 UTC (permalink / raw)
To: gcc
The Steering Committee has, after much deliberation, and after
considering the various opinions presented on the public mailing
lists, adopted the proposal detailed below. This policy will
govern the development of GCC henceforth; it is important that
all developers understand the policy.
As Bernd pointed out, any policy that could be mechanically enforced
is too simplistic. Therefore, there are aspects of this policy that
are under-specified. We will address gray areas on a case-by-case
basis. There are no absolutes; exceptions can be made by the SC to
any of these provisions. And, of course, we understand that this
policy is very likely to require revisions as we go forward.
Although many parts of this policy follow the outline I presented some
weeks back, changes have been made in many places, and, some very
important goals, such as support for more targets, have been made a
bigger focus. I would like to thank everyone for their contributions
to the debate, and especially (in alphabetical order) Per Bothner, Joe
Buck, Robert Dewar, David Edelsohn, Richard Kenner, H.J. Lu, Joseph
Meyers, Alexandre Oliva, Gerald Pfeifer, Bernd Schmidt, and Joel
Sherill for taking the time to make very substantial contributions.
Thank you in advance for your willingness to go along with this
experiment. I hope and believe that it will work out well. If it
does not, we will try something different!
So as to avoid surprising anyone, the first Stage 1 (see below) period
will begin August 15th, 2001. Therefore, GCC 3.1 will be released on
or about April 15, 2002. In the meantime, we will continue to make
bug-fix releases based on GCC 3.0.x.
--
I. Objectives
The goals of this policy are:
- Higher-quality releases
- Support for more targets
- Continued encouragement of major infrastructure improvements
- More predictable release schedules
- More frequent releases
Rationale:
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 liked.
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.
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.
II. Development Methodology
Branches:
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.)
Examples of major changes include:
- A new C++ parser
- A new memory allocation scheme for internal use in the compiler
- A new optimization pass
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.
Changes may be merged from a branch only after:
- 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.
- 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.
Rationale:
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.
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.
Schedule:
Development on our main branch will proceed in three stages. Each
stage will be two months in length.
Stage 1
-------
During this period, changes of any nature may be made to the
compiler. In particular, major changes may be merged from
branches.
Stage 2
-------
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 back-end.
Stage 3
-------
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.
Rationale:
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.
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.
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.
Patch Reversion:
If a patch is committed which introduces a regression [1], on any
target which the Steering Committee considers to be important [2],
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.
After the patch has been reverted, the poster may appeal the
decision to the Steering Committee.
Rationale:
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.
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.
III. Release Methodology
Schedule:
At the conclusion of Stage 3 above, a release branch will be
created.
On the release branch, the focus will be fixing any regressions
from the previous release, so that each release is better than
the one before.
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.
Rationale:
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 previously,
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.
Bug-fix Releases:
Bug-fix releases will be made two and four months after the
initial release, as necessary.
Rationale:
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.
Footnotes
---------
[1] Note that no distinction is made between patches which are
themselves buggy and patches which expose "latent" bugs
elsewhere in the compiler.
[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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Important: Development Plan for Future Releases
2001-07-16 21:03 Important: Development Plan for Future Releases Mark Mitchell
@ 2001-07-17 0:51 ` Joseph S. Myers
2001-07-17 3:38 ` sim instructions [Was: Re: Important: Development Plan for Future Releases] Geoff Keating
2001-07-17 4:02 ` Important: Development Plan for Future Releases Gerald Pfeifer
2001-07-17 8:57 ` Anthony Green
2001-07-18 2:57 ` PATCH for: " Gerald Pfeifer
2 siblings, 2 replies; 9+ messages in thread
From: Joseph S. Myers @ 2001-07-17 0:51 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc
On Mon, 16 Jul 2001, Mark Mitchell wrote:
> any of these provisions. And, of course, we understand that this
> policy is very likely to require revisions as we go forward.
This policy - updated as and when revisions are made - should go in
policy.html or some similarly named file in htdocs (linked to from
index.html and cvswrite.html and maybe contribute.html).
> So as to avoid surprising anyone, the first Stage 1 (see below) period
> will begin August 15th, 2001. Therefore, GCC 3.1 will be released on
> or about April 15, 2002. In the meantime, we will continue to make
> bug-fix releases based on GCC 3.0.x.
The dates and important platforms should also be listed there or in
another such file.
> - 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.
So, which simulators support bootstrapping - running the compiler itself
on the simulator - or, conversely, which are suitable simulators for
microprocessors on which the compiler itself can't run?
There should be a link to http://www.cygnus.com/~geoffk/simtest-howto.html
somewhere, though not necessarily from here.
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 9+ messages in thread
* sim instructions [Was: Re: Important: Development Plan for Future Releases]
2001-07-17 0:51 ` Joseph S. Myers
@ 2001-07-17 3:38 ` Geoff Keating
2001-07-17 4:02 ` Important: Development Plan for Future Releases Gerald Pfeifer
1 sibling, 0 replies; 9+ messages in thread
From: Geoff Keating @ 2001-07-17 3:38 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: gcc
"Joseph S. Myers" <jsm28@cam.ac.uk> writes:
> There should be a link to http://www.cygnus.com/~geoffk/simtest-howto.html
> somewhere, though not necessarily from here.
It would be better to put this in with the main GCC web pages, at the
time the link is created. www.cygnus.com will eventually go away.
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Important: Development Plan for Future Releases
2001-07-17 0:51 ` Joseph S. Myers
2001-07-17 3:38 ` sim instructions [Was: Re: Important: Development Plan for Future Releases] Geoff Keating
@ 2001-07-17 4:02 ` Gerald Pfeifer
2001-07-17 4:11 ` Geoff Keating
1 sibling, 1 reply; 9+ messages in thread
From: Gerald Pfeifer @ 2001-07-17 4:02 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Mark Mitchell, gcc
On Tue, 17 Jul 2001, Joseph S. Myers wrote:
> This policy - updated as and when revisions are made - should go in
> policy.html or some similarly named file in htdocs (linked to from
> index.html and cvswrite.html and maybe contribute.html).
I had prepared this already before Mark's announcement and will
contribute this soon.
> There should be a link to
> http://www.cygnus.com/~geoffk/simtest-howto.html somewhere, though not
> necessarily from here.
Actually, the information there should go into our manual (or at least
our website), I'd say.
Any volunteer(s)? Geoff?
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Important: Development Plan for Future Releases
2001-07-17 4:02 ` Important: Development Plan for Future Releases Gerald Pfeifer
@ 2001-07-17 4:11 ` Geoff Keating
2001-07-18 9:26 ` Gerald Pfeifer
0 siblings, 1 reply; 9+ messages in thread
From: Geoff Keating @ 2001-07-17 4:11 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: gcc
Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:
> On Tue, 17 Jul 2001, Joseph S. Myers wrote:
> > This policy - updated as and when revisions are made - should go in
> > policy.html or some similarly named file in htdocs (linked to from
> > index.html and cvswrite.html and maybe contribute.html).
>
> I had prepared this already before Mark's announcement and will
> contribute this soon.
>
> > There should be a link to
> > http://www.cygnus.com/~geoffk/simtest-howto.html somewhere, though not
> > necessarily from here.
>
> Actually, the information there should go into our manual (or at least
> our website), I'd say.
>
> Any volunteer(s)? Geoff?
The part of it that should go in the manual is already there. The
rest is information about CVS, is only useful to someone who does
not already have the compiler built (and thus does not have the
manual), and will change when the CVS trees are combined.
I'm happy to add the file to the website, but I can't think of a good
place to put a pointer to it. Any ideas?
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Important: Development Plan for Future Releases
2001-07-16 21:03 Important: Development Plan for Future Releases Mark Mitchell
2001-07-17 0:51 ` Joseph S. Myers
@ 2001-07-17 8:57 ` Anthony Green
2001-07-17 11:08 ` Mark Mitchell
2001-07-18 2:57 ` PATCH for: " Gerald Pfeifer
2 siblings, 1 reply; 9+ messages in thread
From: Anthony Green @ 2001-07-17 8:57 UTC (permalink / raw)
To: Mark Mitchell, gcc
Mark wrote:
> Stage 2
> -------
>
> 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 back-end.
Hmm... to a casual observer like myself it seems that adding a _new_
microprocessor port is less risky than _modifying_ an existing port to add a
new variant. Why shouldn't this be allowed?
> If a patch is committed which introduces a regression [1], on any
> target which the Steering Committee considers to be important [2],
"target" shows up more than "host" in this note. What about regressions on
different host platforms?
Ignoring test code, I believe that more than half of the source files in GCC
are part of some target library and not the compiler. Your note has very
little to say about target libraries. Am I right to assume that the library
maintainers are to work within the spirit of this plan, but have more
flexibility?
AG
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Important: Development Plan for Future Releases
2001-07-17 8:57 ` Anthony Green
@ 2001-07-17 11:08 ` Mark Mitchell
0 siblings, 0 replies; 9+ messages in thread
From: Mark Mitchell @ 2001-07-17 11:08 UTC (permalink / raw)
To: Anthony Green, gcc
> Hmm... to a casual observer like myself it seems that adding a _new_
> microprocessor port is less risky than _modifying_ an existing port to
> add a new variant. Why shouldn't this be allowed?
It should be. In fact, there's talk of adding a new port to the GCC
3.0 branch, and I think that's fine, as long as the new code is
in decent shape, and there's little or no impact on existing code.
> "target" shows up more than "host" in this note. What about regressions
> on different host platforms?
That matters too. You can read "host" for "target" throughout, I
think.
> Ignoring test code, I believe that more than half of the source files in
> GCC are part of some target library and not the compiler. Your note has
> very little to say about target libraries. Am I right to assume that the
> library maintainers are to work within the spirit of this plan, but have
> more flexibility?
I'm not sure how much more flexibility makes sense. If I can't build
the library, I can't really use the compiler, so it's just as broken,
in many ways. So, I don't think reading anything specially for libraries
was what was intended. (It's a little confusing, because I know exactly
what I intended, but I don't know exactly what the SC intended,
collectively so I'm hedging a little bit.)
Java has gotten special treatment up until now because it's been in
such a formative state. I think it's reasonable to continue operating
in that mode a little while longer, but then now that the GCC 3.0 release
is out, with pretty good Java support, I think we need to start treating
it pretty much like the rest of the system.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* PATCH for: Development Plan for Future Releases
2001-07-16 21:03 Important: Development Plan for Future Releases Mark Mitchell
2001-07-17 0:51 ` Joseph S. Myers
2001-07-17 8:57 ` Anthony Green
@ 2001-07-18 2:57 ` Gerald Pfeifer
2 siblings, 0 replies; 9+ messages in thread
From: Gerald Pfeifer @ 2001-07-18 2:57 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc, gcc-patches
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.)
Installed.
Gerald
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>.
<h2>News/Announcements</h2>
<dl>
+
+<dt><b>July 17, 2001</b></dt>
+<dd>
+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.
+</dd>
+
<dt><b>July 9, 2001</b></dt>
<dd>
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 @@
+<html>
+<head>
+<title>GCC Development Plan</title>
+</head>
+
+<body>
+
+<h1 align="center">GCC Development Plan</h1>
+
+<h2>Objectives</h2>
+
+<p>The goals of this policy are:</p>
+
+<ol>
+<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>
+</ol>
+
+<p><strong>Rationale<strong></p>
+
+<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
+liked.</p>
+
+<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>
+
+
+<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, 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>
+
+<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 use a simulator for
+validation; the use of real hardware is not required.</p>
+</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>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
+back-end.</p>
+
+<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><strong>Rationale</strong></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
+patch.</p>
+
+<p>After the patch has been reverted, the poster may appeal the
+decision to the Steering Committee.</p>
+
+<p><strong>Rationale</strong></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>
+
+
+<h3>Schedule</h3>
+
+<p>At the conclusion of Stage 3 above, a release branch will be
+created.</p>
+
+<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
+before.</p>
+
+<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><strong>Rationale</strong></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><strong>Rationale</strong></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>
+
+<hr>
+
+<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>
+
+</body>
+</html>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Important: Development Plan for Future Releases
2001-07-17 4:11 ` Geoff Keating
@ 2001-07-18 9:26 ` Gerald Pfeifer
0 siblings, 0 replies; 9+ messages in thread
From: Gerald Pfeifer @ 2001-07-18 9:26 UTC (permalink / raw)
To: Geoff Keating; +Cc: gcc
On 17 Jul 2001, Geoff Keating wrote:
> The part of it that should go in the manual is already there. The
> rest is information about CVS, is only useful to someone who does
> not already have the compiler built (and thus does not have the
> manual), and will change when the CVS trees are combined.
>
> I'm happy to add the file to the website, but I can't think of a good
> place to put a pointer to it. Any ideas?
I, too, don't have any idea I *really* like, but how about adding this
at the end of the FAQ (faq.html), for now?
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2001-07-18 9:26 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-16 21:03 Important: Development Plan for Future Releases Mark Mitchell
2001-07-17 0:51 ` Joseph S. Myers
2001-07-17 3:38 ` sim instructions [Was: Re: Important: Development Plan for Future Releases] Geoff Keating
2001-07-17 4:02 ` Important: Development Plan for Future Releases Gerald Pfeifer
2001-07-17 4:11 ` Geoff Keating
2001-07-18 9:26 ` Gerald Pfeifer
2001-07-17 8:57 ` Anthony Green
2001-07-17 11:08 ` Mark Mitchell
2001-07-18 2:57 ` PATCH for: " Gerald Pfeifer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).