Re: requalification of arm as etch release architecture
ARM based systems are low power, small and much more mobile than x86.
Consequently, they often and quickly change administrative domains.
Joey Hess asked:
> [...] is there enough value in a stable Debian release for arm to
> justify the additional load that releasing another architecture will put
> on the release, security, installer, etc teams?
Of those three, I suspect that the installer aspect is the least critical.
Consider the delivery of a custom system (eg prototype) at a fixed price;
the customer quite reasonably expects reliability and reproducibility,
and all support work has to be factored into the price that is quoted.
The long term reliability is only achievable with security support,
and even the short term is heavily dependent on the freezing process.
Reproducibility implies that archives are available for a full rebuild.
This is known to be impossible for Testing ... without a local buildd.
The consequences after delivering Testing have enough of a price tag
that it is worth changing hardware and CPU architecture to avoid it.
> Or would using testing and/or snapshots for arm deployment work well
> enough for most Debian arm users?
Not for the projects with which I'm involved.
Imagine delivering a Testing based system to the customer, after which
the local administrator needs to install software to ensure that it
plays nice with the corporate network environment in which it resides.
Since Testing is a moving target, and the system probably spent several
weeks in shipping and release clearance, there is an excellent risk
that this software addition will require some of the existing installed
packages to be upgraded. That local administrator has a choice; either
do the upgrade and end up with an untested/unsupportable configuration,
or not do the upgrade and be unable to attach the system to the network.
It is unsupportable because:
(a) it used unstable's toolchains, libraries and dev package versions,
(b) by the time he knows he has a problem, those package versions may
already have fallen out of Testing's archive and not be available.
> I doubt there are a lot of people running arm on serious servers,
It would be helpful to know your definition of "serious servers";
Taking the popular definition of "costs more than $10k", I agree.
Eval boards often cost more, but are rarely deployed as servers.
> and so I question whether
> those using arm for the more or less embedded type stuff that's common
> for this architecture really need a stable release.
Your question is moot for appliances and truly embedded computers;
no "Debian" administration, or distinction between stable and testing.
These are really using Testing as a big SDK, not as a distribution.
I'd be surprised if they don't do a subsequent freeze and betatest.
On the other hand, embedded can also mean "small and inside something".
Unmanned vehicles and sensor/security systems are considerably more
expensive and failures have serious consequences beyond profitability.
If such a unit is a prototype or an inherently reconfigurable design,
it is not feasible to freeze and run regression after every "apt-get".
>From Wookey on Wednesday, October 12, 2005 8:40 AM
> Many of these are classic servers which don't get fiddled with often at which
> stable is targetted. So stable probably is being used, and after a period of
> decline is perhaps going to be used more that it was?
The most expensive aspect of any non-appliance is the administration
and the easy way to make that cheap and efficient is to have the unit
behave exactly like every other managed computer on the network.
With AMD64 based servers running Stable, I think ARM should too.
> So, I'll defer judgement till we have a bit more feedback about our users
> and people developeing using a Debian base
Concepts flow from research, through development, demonstration, design,
field test, prototype into production. Research computers may be fast
SMP AMD64, yet the production computer could be a ARM9 or PowerPC SOC.
The linux kernel is equally applicable, so software can migrate along.
Debian is in routine use for the first three or four stages, and the
EmDebian project looks like it will nicely fill many production roles.
In order to maintain engineering continuity and cost efficiency,
the field test and prototype computers should also be running Debian.
These are usually deliverable to the customer, so need to run Stable.
If Debian/Stable/ARM isn't an option, it will pretty much kick the
ARM processor out of the production spots because all of the customer
evaluation will have occurred using something from x86 or PowerPC.
Similarly, if the production system is known to have to use ARM,
that project needs to migrate away from Debian at the design stage.
Hope that helps,
Alex.
http://lists.debian.org/debian-arm/2005/10/msg00019.html
http://wiki.debian.org/armEtchReleaseRecertification
http://spohr.debian.org/~ajt/etch_arch_qualify.html
Reply to: