* Helge Deller ([email protected]) [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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
