Thanks, Bruno. The change to gnulib.texi looks good, but my kneejerk reaction to the proposed change to gnulib-intro.texi is that although much of what's proposed is useful, it divides software into categories pretty strictly and this strictness might cause confusion and problems. For example, I test gnulib code on Solaris more often than every six months, so in that sense Solaris is more important than what its "major" listing would imply. Conversely, some free software is maintained for more than three years after release by organizations like Red Hat and Ubuntu. Overally I suspect it'd be better to keep support levels a little fuzzy, and not to try to define terms like "essential" and "minor".
Instead, how about something like the following: @node Target Platforms @section Target Platforms Gnulib works on a number of platforms that we call the "reasonable portability targets". GNU platforms, such as glibc, have the highest priority. Next come other free-software platforms, such as Cygwin and FreeBSD. Then come proprietary platforms that fit well in the Unix/POSIX tradition, such as MacOS X and Solaris. Then other proprietary platforms that are a bit of a stretch, such as mingw. And last comes proprietary platforms that would be so much of a distraction to support that Gnulib deliberately does not support them, such as MS-DOS. Once the original distributor of a platform version stops supporting it, it is typically no longer important to Gnulib as well. However, already-existing Gnulib code for now-obsolete platform versions is typically left in place unless it would significantly impede maintenance on modern platforms. The exact set of platforms and platform versions, and their level of support, is open to judgment and depends on how much work developers are willing and able to contribute. Volunteers to help support other platforms are welcome, but should keep in mind that Gnulib's goal is to support production applications, not computer museum pieces or software research projects. Here is a list of platform versions, written in 2011, that indicates a reasonable set of priorities for Gnulib: [at this point insert the list of platforms from Bruno's email, starting with glibc systems]
