I would suggest to pick a generic, short name, with we could reuse
later if it is proven that hardfloat has no sense in the next years.
Comments?
I suggest just the opposite. :)
We should pick a name that is clear and concise, so that it doesn't collide with another name we'd like to use later. For example, I'm glad we dropped "arm" because it tells me very little in detail about _which_ ARM machines are supported. And there aren't a lot of people you can ask about stuff like that who have a truly informed answer.
I don't see them all becoming official Debian ports, but it would be awfully nice to someday have several repositories to choose from depending on whether you want least-common-denominator Debian for ARM, packages that have been built with compiler optimizations for Cortex A8, or XScale, or whatever. And then big/little-endian, EABI/OABI, SMP, and whatever else comes along later.
I think the howls of maintenance protest are somewhat justified, but you just can't go wrong with names like "arma8vfpel", "arm920tel", and so on. In an ideal world, I would prefer we go that route. To me, names like "armel" are just too generic to be meaningful.
I'm speaking from the perspective of someone who uses Debian (and emDebian) across the full range of ARM machines. For embedded applications, mostly. So the clarity is important to me, even if the names are somewhat inconsistent with the tidy, generic names that Debian uses for its architectures now.
It would be really cool if we could find a way to make it easy to launch a buildd to create packages for, say, "A8 with VFP and EABI", and the package scripts somehow tolerate a new ARM-based arch name that they haven't seen before because I'm the first guy to try to optimize for a certain machine.
b.g.
--