This is the mail archive of the
mailing list for the GCC project.
Re: gcc 3.5 integration branch proposal
> "Same high quality"? I know you're aware of them, but you might want
> to revisit the reasons that _no vendor_ I know of in several years has
> shipped an FSF released compiler. Even Debian, which is chronically
> short of the talented manpower required for compiler development, ships
> fifteen hundred lines of GCC patches plus a bleeding edge 3.3-cvs
> snapshot last I checked. The people with real budgets, like SuSE and
I really tend to believe that hammer branch has possitive effect on FSF
release quality. One thing SuSE can and FSF can't is to give patches
fair amount of testing. Via Hammer branch many defects of
unit-at-a-time and profiling and other changes we do use were discovered
so it will hopefully make 3.4 easier to stabilize.
I really hope that when (if) 3.4 will be accepted for SuSE, I will be
able to throw 90% of the changes we have as they were in some form
merged into 3.4. Location lists is last major change remaining. I have
little understanding of this area, so can't really tell what is causing
it to be offending so much.
I plan to get deeper understanding once we will re-try send it for 3.5.
> Red Hat, have orders of magnitude more changes.
> I suspect the primary users of the release tarballs are roll-your-own
> developers (mainly either embedded or need-a-newer-C++) and large site
> installations (universities, corporate, etc.) who have a stable
> existing OS with an older compiler.
> Obviously we want higher quality releases. But now that CodeSourcery
> is doing the exact same thing as all other vendors, I'm sure you can
> see why it happens, and holding off releases isn't going to help
> anything. My utterly unqualified instinct says that postponing the
> release branch isn't going to help, since developers and vendors have
> absolutely demonstrated their willingness to work outside of the trunk.
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer