> as i mentioned before, unless there's an actual issue, i'm a big fan > of pushing version upgrades so that any problems can be identified > sooner rather than later. if a newer version of some toolchain > component works on all but one architecture, i think it's more useful > to bump the default version, except in the case of that one > architecture (which is what the binutils Config.in would be doing > anyway WRT to avr32, which doesn't have patches for binutils-2.18).
Although I can appreciate your enthusiasm for new versions (I run Gentoo), the unfortunate truth is that it takes a great deal of QA to get a particular portion of the toolchain working for an architecture. Unless a new feature (like processor support) is utterly necessary or the current tool is actually broken, I believe it a much better use of a development team's time to focus on bug-squashing and adding their own features rather than ensuring compatibility with fubar-2.81.6.4-r20. Of course, that needs to be balanced in order to avoid a situation like RedHat encountered with gcc-2.95, but all things in balance. More often than not, allowing revisions to "languish" provides a good buffer to allow the very problems you are concerned with to be sorted out at the originator's level. That doesn't mean developers shouldn't be aware of upcoming features and code themselves into corners, but unless there's a dedicated toolchain person or team, the toolchain treadmill is a big one to avoid. In my not-so-informed opinion, early problem identification is not a sufficient nor particularly reasoned justification for attempting to keep up with the ragged edge of toolchain development. Developers for project X are there to work on project X, and not typically to troubleshoot interactions with the toolchain. RB _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
