> On Tue, Jan 22, 2008 at 10:01:55AM +1100, Ben Elliston wrote: > > My understanding is that NetBSD port to the vax is very much alive and > > maintained. Thus, I expect that those users (eg Matt Thomas) would like > > to see the GCC port retained. > > How can we encourage the NetBSD folks to participate more directly, > including helping to test the trunk? I haven't been following NetBSD > carefully, but I get the impression that at least some of the BSDs > work with older gcc branches, staying away from the bleeding edge, > and this could put some of their ports at risk if we have no one to > test the compiler.
Here are a few of my thoughts and suggestions on this issue: 1) From personal experience, I know that it is a major commitment for someone to become a port maintainer. It takes a lot of time to keep a port going at the bleeding edge. In addition, skill is needed to argue the merit of changes to the compiler outside the area of responsibility of the port maintainer. The maintainer may have to maintain a farm of machines with different operating systems. In my case, I have been fortunate that the National Research Council of Canada has provided space and resources for machines. HP has donated a number of machines. For folks primarily interested in an OS port, the GCC requirement to build and test the port on a regular basis is just another hurdle in getting their port working. Thus, I can see why many hesitate to become port maintainers. 2) For ports that support full blown operating systems, it would seem that simulators provide a mechanism to develop and test these ports. Current PCs certainly have the power to do this testing. So, it might be helpful if a set of GCC test simulators were setup and available for download. 3) I think the GCC release cycle may be too fast for many distributions. We also may be closing branches too early. I believe TheWrittenWord is using 3.4 for its HP-UX and AIX distributions. Apple Panther used 3.3, Tiger 4.0.1. Don't know about Leopard. Debian Lenny is using 4.1 and it's not yet stable. The main point is distros pick a GCC version and stay with it for the life of each distribution. It's quite possible that the GCC project will stop maintainence of the version being used before a distribution is released. As a result, I think the distros have to perform their own GCC maintenance. Nobody is going to pay any attention to a bug reported against a GCC version that is no longer maintained unless it is still present in the head. 4) The GCC project may be too strict about applying fixes to previous releases. The home page suggests that only regression fixes can be applied to previous releases. In practice, the project isn't that strict and allows fixes for important bugs to be applied to previous releases if they aren't risky. I can point to at least one situation where blindly freezing a product has led to a situation where the application is non functional for many users and the company is ignoring requests for a fix. As a result, the company is experiencing a public relations nightmare. The main reason I mention this is that it may take one or two releases before the cause of a bug surfaces when a port has limited support. I don't think GCC has major product problems but it might be interesting to do a statistical study of bugs reported against released versions. In sumary, there is a tricky balance in all this. The stage1 renewal is clearly essential for the health of GCC. On the otherhand, we can't lose sight of the fact that GCC is a tool that must be reliable and standards complient. Sometimes stage1 requires a lot of work on the part of port maintainers. Port maintainers often have to do the initial leg work to debug and classify bugs. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
