Re: open issues with the hppa port

[Andreas Barth <aba@not.so.argh.org>]

* Helge Deller (deller@gmx.de) [090731 23:32]:
> So, if we have stability problems on the most important machines,
> which are the debian build servers, then maybe some thoughts should be
> given to replace those machines by slower but at least stable machines,
> like e.g. a C3000 ?

We need to have fast and reliable machines. One of the reasons for
fast is that we want to be able to build an security update for any
package in a resonable time frame. It is no longer acceptable that we
need to wait more than 5 days for a single architecture till we can
upload (we had that with m68k) - I'm not sure how much slower these
machines are, but for sure hppa isn't the fastest port anyways.
(Another reason is that we want to keep up with at maximum 2 buildds,
to reduce admin overhead.)

Doing a stable release means also that we need to be able to support
the architecture for at least 3 years starting from the next stable
release on. Depending on when that will happen, that is 4-5 years from
now.


Any architecture (that isn't parisc related anymore) has more or less
4 stages:

First the architecture comes up fresh (e.g. currently kfreebsd*), so
we have a lot of porting issues. Fast machines are sometimes not too
often, as there are only development boards available etc. For the
very first steps, we often have an seperate archive till the
architecture is stable enough to be integrated.

Then the architecture is stable, we have fast machines, good tool
coverage (e.g. currently amd64), it's easy to buy a machine. Most of
our architectures should be in this stage.

Then, at some point, the hardware is no longer available new, but the
architecture is still usefull to people. We slowly notice that more
and more issues happen. There will be a point in time when the effort
to support the architecture in stable outweights the bonus of still
running the architecture. There will be a time when we cannot do
stable releases anymore. If we cannot do new stable releases anymore,
we cannot host porter machines anymore, so the architecture will need
to go away from unstable after security support for the last stable
release is ended. At the end of that stage, an own archive might be
helpfull as well.

Then the final stage: There are neither porters nor useable hardware
left anymore. End.


Any architecture will be in the final stage at some point in time.
E.g. we already EOLed support for the 80386-cpu, as well as for the
old arm port.

As far as I can see, hppa is currently in the third stage: The
hardware isn't available as new anymore, but the port is still usefull
to people.

I haven't made up my mind yet whether it is better to include hppa in
the next stable release or not. If we notice that the issues that we
have will be fixed / worked around, then the answer to the question is
easy. If we notice that probably we won't have working buildds
available then the answer is ... well, not easy but obvious.

I notice that quite many people are working on / using hppa. However,
there are issues which we have for quite some time, e.g. the switch to
nptl. When I looked first at hppa during my time in Debian (I don't
know when that was, but quite some time ago), I think we already had
the "we will switch to nptl soon, most issues will disappear with
that". I'm happy if the switch happens. But we cannot wait forever if
this is the precondition for supporting hppa with squeeze.


Currently, the state is quite ambigous. The german saying for that is
"zum sterben zu viel, zum leben zu wenig", means: not really stable
enough to support it, but not really broken enough to remove it. We
need to leave that state that just causes pain on all sides.

I would like to reach consensus with the porters how we can leave that
state, and to which direction. That's one of the reasons why I asked
for a plan to reach the state of "hppa is a normal stable
architecture". A proposal of such a plan with (maximum) timeframes
will allow us to either agree that this doesn't work (e.g. takes way
too long for DSA or the security team, or way too less time left for
the porters), or - and that's of course the hope - have a buy-in from
all on the plan and get hppa back in the "it's stable" yard. Also we
can see what preconditions are necessary, e.g. "we need a problematic
machine for porter $name" or "new hosting for machine $name needed" or
whatever.

The important thing on planing that is also to have a common
understanding and common expectations. After the proposal of such a
plan, anyone who has issues can review if his issues are there. If
not, we can discuss if the issue is worth being mentioned there. That
makes sure for the porters that after the review it is quite unlikly
that existing issues will pop up quite late in time.



Cheers,
Andi