RE: GCC 3.3, GCC 3.4

["Scott Robert Ladd" <scott at coyotegulch dot com>]

> That means that you would expect to see people fixing bugs now.  I don't
> believe that people push in half-finished features from branches and
> then move on to the next project.

I'm responding to Mark's concern about people adding features and then
moving on to "cooler" activities without participating in bug fixing and
testing.

> If "management" wanted the features to be merged, it's
> probably in their interest that they actually work, too.

Perhaps I misunderstood; I thought Mark was refering to "paying" company
managers who employ people that work on gcc. There has been a problem in the
past with commercial firms releasing "versions" of gcc that are incompatible
with FSF gcc. Such developments are created for the good of the commercial
company, and compatability with the world at large is not important.

Considering the buggy nature of many commercial projects, please forgive me
if I lack faith in management's desire to see things "work."

> In addition to that, there are important areas of common interest.  For
> example, compiler speed.  This is now a "focal point": The "players" all
> have the same interest here, so it's more than likely that it will be
> fixed one way or another.

I've had a lot of correspondence with people who are very concerned with
gcc's speed; many are working with platforms that do not fall within the
purview of the "players."

Once a technological path is taken, it is difficult to back-track; what may
be a good idea for x86 Linux developers is not necessarily good for all
users of gcc.

> (Let's just hope that no new branches with major work like that show up
> for a while... That too is in everybody's interest IMHO.)

I most heartily agree.

> > A reliable, functional gcc is critical to the success of free
> > software; it is the foundation upon which the other packages
> > rest. Somehow, we need to impress this upon the commercial
> > vendors who fund development. Freedom exists because of
> > cooperation; if the developers of gcc do not cooperate, free
> > software will not succeed in the long run.
>
> Let's not over-dramatize here.  Fact is that GCC right now is better
> than ever before, just slower but like I said, that's something that can
> and will be fixed, *because* it's in everybody's interest.

I agree the gcc is better than ever before FOR SPECIFIC ENVIRONMENTS. I have
heard from many people who can not use the current gcc because it's compile
times are excessively slow in their environment.

Commercial sofwtare is driven by marketing; free software is driven by who
is willing (and ABLE) to do the work. In both cases, biases exist that may
not be good for the user community as a whole.

> Linu[sx] has a completely different management style.   The FSF does not
> like forks and separate source trees at all. Linus *encourages* forks!

I find it humorous that "free as in speech" software is against the freedom
to create forks. But the definition of "free" is something best left to
another forum... ;)

> GCC is a single big system from the middle end to assembly, and even the
> front ends are not entirely separate.  So the linux model doesn't work
> for GCC.

I wasn't clear; my apologies. I don't expect gcc to be manage in the same
fashion as Linux. However, I believe that gcc's current direction favors a
development model that may not be in the best interest of gcc's users.

> Therefore I would think that it is in the vendors' interest that there's
> only one GCC.

Therein lies the problem -- Mark is correct that gcc needs to address the
needs of commercial vendors, lest they create (as they have in the past)
their own unique, incompatible versions. However, commercial concerns may
not necessarily mesh with each other (Vendor A may want feature X, while
vendor B wants Y) or members of the broader community (compile speed).

..Scott