I woudn't be particularly happy with that unless the gcc maintainers ok
it, and I'm still not sure that two days is also an acceptable
timescale.

then please drop mips and mipsel as release architectures. At least

What is your problem about MIPS? Why do you insist about dropping it? At
least be fair and don't spread FUD.
GCC on mips/mipsel build in less than 2 days on the recent build
machines. It's true that the build time is slightly higher than other
architectures, but the testsuite is done on 3 different ABIs. This is
something that can be tweaked, as suggested for SH4.
Here are the average build time for gcc-4.* since the release of
Squeeze [1]:
| mips | mipsel |
--------+--------+--------+
gcc-4.3 | 42864 | 141863 |
gcc-4.4 | 104400 | 149148 |
gcc-4.5 | 123498 | 114435 |
gcc-4.6 | 95725 | 167799 |

gcc-4.6: 167799/3600 = 46.61, and this is with the libstdc++ testsuite already
disabled, because it did timeout or fail on the mipsel buildds. So this is *no*
FUD. Did you look at the build failures, or some other mips porter, before I
did disable the tests?

The build time dispersion is explained by the fact we have buildds of
different speed, gcc-* is built by default on them (no_weak_autobuild),
unless this build daemon is already busy.

sh4 has a workable, accessible developer machine,

mips also has an accessible developer machine, gabrielli.debian.org.
It's true that mipsel doesn't have one (it's being working on), that
said, most issues are reproducible on both. People can also ask on
debian-mips for help in case it's a mipsel specific issue.

yes, the last one incomplete and only completed by myself. So who else is doing
toolchain work on mips in Debian? Thiemo did leave a big gap, and it was an
effort of many people to release squeeze with mips. I just see that

All that said, I agree that mips and mipsel architectures are not in
their best shape, but people are working on that. If you consider they
don't follow the release criteria, please give objective arguments.

the build time argument was brought up by the debian-release team, so this this
seems to be an objective argument. If not, maybe the release criteria for new,
current and "obsolet" ports should be made more transparent. I'm only aware of
one table not differentiating new and current ports.

yes, other issues are the non-availabilty of a mipsel porter box and the
instability of the existing mips porter box.

and toolchain maintenance was rather difficult (longsoon, binutils) during the
squeeze cycle.

Matthias

Please note that this thread did start about sh4, and some comments about the
sh4 toolchain by some members of the release team, which apply for mips* too,
and which are used against the sh4 port.

I appreciate your work on mips, but I think a lot more needs to be done to keep
it as a release architecture, and that arguments that are overlooked by intent
for existing release architectures should not be used against a new port.