GOTO Masanori <firstname.lastname@example.org> writes:
> One concern item is this 2.3.2-1 freezes sarge again due to FTBFS on
> mips64 support (mips/mipsel), unwind (m68k/arm/hppa). It needs some
> periods to fix. However we provided the previous 2.3.1-17 (it did not
> build on mips/mipsel though), so it does not become the big problem to
> release sarge (but I think sarge should use 2.3.2 or later).
Err, sorry, but it is a big problem. Do you not understand how
testing works? When you upload 2.3.2-1, all the maintainers tracking
unstable (and I'd guess it's the majority) will start compiling their
packages using it. When they do that, they're packages (and anything
that depends on them) instantly becomes backlogged on the new glibc.
Worse, you're uploading the new glibc knowing it doesn't compile on
release candidate platforms.
Please (with a cherry on top), think about this, we're never going to
get anywhere if we stall for another 6 months waiting for glibc to
become releaseable again. Why can't you get glibc compiled and tested
on all release candidate architectures before uploading it to
unstable? (e.g. Why not upload 2.3.2-1 to experimental?)
- From: GOTO Masanori <email@example.com>