NightStrike wrote:
On Thu, Mar 19, 2009 at 3:06 PM, Steve Kargl
<s...@troutmask.apl.washington.edu> wrote:
On Thu, Mar 19, 2009 at 07:46:37PM +0100, Toon Moene wrote:
I agree about the bisecting-in-case-of-bugs issue.
However, what I see happening in practice is that all GCC developers
keep on doing their development work on branches - only the gfortran
developers are left out, because they do not have a branch.
Of course we can create branches for all the subprojects that are
pending on the creation of a 4.4 branch and freeing up trunk - it just
doesn't seem very efficient to us.
Of course I pleaded with the FSF (on the Steering Committee mailing list
*and* the gcc list) for speed in the case of the 4.4 branch - in vain.
We might be heading for a fork a la the EGCS fork - and I don't like it.
It took a lot of effort (I was part of the EGCS cabal and I didn't
even do a lot of that foot-work).
"Those who do not learn from history are doomed to repeat it."
George Santayana
http://home.schmorp.de/egcs.html
Why are we doing this? It's become increasingly clear in the course
of hacking events that the FSF's needs for gcc2 are at odds with the
objectives of many in the community who have done lots of hacking and
improvment over the years. GCC is part of the FSF's publicity for the
GNU project, as well as being the GNU system's compiler, so stability
is paramount for them. On the other hand, Cygnus, the Linux folks,
the pgcc folks, the Fortran folks and many others have done
development work which has not yet gone into the GCC2 tree despite
years of efforts to make it possible.
This can be amended by replacing "so stability is paramount for them"
with "so utopian philosophical pander is paramount for them"
--
Steve
http://gcc.gnu.org/ml/gcc/2009-03/msg00439.html
I would agree that going back to stage 3 is really a good solution. I
have also read several of the historical threads that are similar to this.
First, a clarification. This proposed development branch is in no way
intended to be a fork. That would be disrespectful of the gcc community
and I could not support such a thing.
Creating the branch allows us to continue joint effort much like other
gcc developers do already. This is nearly an ideal time because we are
talking significant changes that go beyond Fortran95 and move well into
Fortran 2003/2008. That's what development branches ae for.
If the 4.4 delay continues only a little while or a longer time, we are
capable of managing the merging in an orderly manner.
Therefore I believe the Yea's have it and I will attempt to create the
branch hopefully this weekend. We will follow our usual practice of
peer review before commits.
Paul, do you have time to organize an IRC meeting to discuss order of
commits and any other concerns? or Tobias?
Regards,
Jerry
