Re: 2.3.2-1

[GOTO Masanori <gotom@debian.or.jp>]

At Mon, 12 May 2003 12:17:13 +0100,
James Troup wrote:
> 
> GOTO Masanori <gotom@debian.or.jp> 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.

I know, I know.  So I didn't dupload 2.3.2-1 until now.

In first, some bugs are remained in 2.3.1.  You can see a lot of bug
fixes in 2.3.2-1.  They are really problems for sarge.  The most
concern item is dynamic loading problem, sparc64, hurd-i386.

2.3.1-17 is based on 2002-12-02.  Five months before.  Many bugs are
fixed.  Upstream released 2.3.2 at the same time to release RH phoebe
(RedHat 9), then two months is passed.  I'm requested to release 2.3.2
by some persons.  Sometimes "release sarge" is not the first target
for all users/developers.

I cheer each architecture porters to work it :-) (If not, I should
work it, well...)

> 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.  

To be honest, I think debian should have the exact release date and
plan.  The current roadmap is very rough, so I don't believe sarge is
really released after 6 months later _without_ any RC bugs.  The
current release framework is difficult to decide when I can dupload
2.3.2-1.  Glibc is the really difficult package to keep healthy
everytime (and you know it's impossible) because we have a lot of
different architectures.

> Why can't you get glibc compiled and tested on all release candidate
> architectures before uploading it to unstable?  

James, do you know glibc is _different_ from other packages?

  - Please tell me how to test it on _all_ architectures.  Glibc needs
    _real chroot_, so I have to become _root_ user.  Actually I tested
    glibc on various architectures with ISHIKAWA Mutsumi's private
    machine (he lend his machine to me kindly.  Thanks to ISHIKAWA-san!).

  - There is no mips/mipsel public machine.  Thus I can't compile on
    _all_ architectures.  Sometimes I hit the problem that dchroot
    environment is not well prepared (ex: powerpc voltaire).

And I checked frequently to build on some architectures.  If you can,
please issue me the account for all architecture including mips/mipsel
to test glibc.

> (e.g. Why not upload 2.3.2-1 to experimental?)

Well, this seems an idea, but still many bugs are remained in BTS.
Debian glibc stores up many bugs.  In addition I warn you if we avoid
to release 2.3.2-1 now, I can't predict when we update glibc into the
latest.  I think it's good time to dupload it.  Please consider my
decision?  I consider and select the decision to dupload it.

I would like to know you and other developer's opinion.

Regards,
-- gotom