Mike Hommey schrieb:
> On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote:
>> Luk Claes schrieb:
>>> Matthias Klose wrote:
Grant Grundler schrieb:
> On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
>> Grant Grundler wrote:
>>> On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
>>> http://lists.debian.org/debian-release/2009/04/msg00303.html
>> Note that it's wrong to assume we will come with the answers.
> I was expecting a summary of specific issues from an organization
> that claims to operate transperently. The hand waving is easy. But
> doesn't resolve problems and doesn't meet my expectation of an "open"
> organization that I've donated money, time, and materials to.
+1. dropping hppa as a release architecture was not communicated by the
release
team at all. I did spend some time to get gcj / default-jdk working on
hppa,
and some money (buying a new disk for a hppa machine) to help this port.
The
time and the money could have spent better, if d-r would have better
communicated about their intent.
>>> There are issues with the hppa port where the release team considered
>>> dropping it since 2005 communicated to the porter list...
>>>
hppa is not in a good shape, but there are other architectures which are
not
better (sparc, mips*) from a toolchain point of view. what about these?
>>> I'm not aware of current toolchain issues on sparc and the issues on
>>> mips* still seem to be manageable, no?
>> sparc-biarch defaulting to 32bit isn't supported by upstream; there are
>> requests
>> to move to v9 optimization by default, which requires some work in the
>> compiler.
>> I don't plan to update this for upcoming GCC versions, and there's no
>> interest
>> by upstream to help with this kind of setup. You can't buy v8 software for
>> years
>> now, but afaik all our machines run 64bit kernels. Maybe it's time to
>> acknowledge this, remove sparc from the list of release architectures and go
>> on
>> with sparc64?
>
> Isn't sparc64 a full 64 bits port ? sparc is unfortunately not amd64,
> where the pros of the added registers overcome the cons of bigger
> pointers. In other words, 64 bits code is slower, fatter and more memory
> hungry than 32 bits code on sparc.
which of the previous statements did you check? E.g. speed comparing the current
32bit v8 with 64bit ultrasparc code?
and even then I wouldn't care that much if it becomes maintainable.
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
