Re: Beyond GCC 3.0: Summing Up

[David Edelsohn <dje at watson dot ibm dot com>]

	This discussion is an example of a larger issue that the GCC
development community needs to face: how much of a "process" should the
GCC Steering Committee and Release Manager impose?  It is impossible to
fully implement a traditional development "process" when all developers
are volunteers.  Some of the "process" can be imposed unilaterally; the
question is how much.

	No one works for the SC and RM.  We cannot impose a strategy, a
plan, reviews, verification, release engineering, cooperation, etc.  E.g,
we cannot create a design for GCC infrastructure and optimizations which
the volunteer developers must follow.  We cannot get developers to fix any
particular part of the compiler that they broke or help with a part of the
compiler for which they have expertise.

	 Developers are adding optimizations, but GCC is not getting
better in a coherent manner: it is getting slower and not producing better
code.  The only thing which appears to be improving is language standards
conformance.

	The only things that the SC and RM can do are:

1) Stop others from doing things in the FSF sources (e.g., revert patches)

2) Make a tarball and call it a release.

Period.  End of story.  Everything else is cajoling people and altruism.
The SC and RM cannot force other developers to do anything and we cannot
develop GCC without help from others.

	So the questions for the GCC development and user communities are:

1) How does it want the SC and RM to apply the limited tools at its
   disposal?

2) How can the SC and RM produce good GCC releases on a regular schedule?

Note that the two issues are tied together.  It is a balance.  We need the
GCC development community and the GCC user community to help decide how it
wants us to use our power to implement the goals.

	Everyone wants regular GCC releases with new features, bug fixes,
and correctness on their platform of interest.  How do we get there from
here?  How can the SC and RM accomplish that goal?  If we do not impose
enough "process", we never can produce a release on any schedule.  If we
impose too much of a "process", developers are pissed off.  We cannot
please everyone, but we need to find a balance that everyone can live with
as part of the community development of GCC.  We do not have a magic wand.

	I would appreciate if everyone arguing about reverting or not
reverting patches and making releases on a schedule would think about
those issues and their positions/opinions in this larger context presented
above.

	Hopefully people can respond with constructive comments to help
the GCC SC decide these issues.

Thanks, David
===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje@watson.ibm.com                                  P.O. Box 218
+1 914 945 4364 (TL 862)                            Yorktown Heights, NY 10598