[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: requalification of arm as etch release architecture

On Sun, Oct 09, 2005 at 12:45:09PM -0400, Joey Hess wrote:
> Following up on last night's irc meeting[1], which had a preponderance
> of arm (and armeb) people in attendance compared to most architectured,
> there is the start of a page for requalifying arm as an etch release
> architecture here: http://wiki.debian.org/armEtchReleaseRecertification

Thanks Joey

> This is also a useful overview:
> http://spohr.debian.org/~ajt/etch_arch_qualify.html, showing that arm is
> problimatic in the areas of:
>   - Not currently having a developer accessible machine;

This is *purely* down to the admin team, hardwares been available (in
the required Debain admin format) for over a year...its one of those
things that our admin team is really really busy and this is a big job
that they (quite rightly) wont delegate. When their ready it will

>   - Not having enough Debian developers listed as port maintainers;
>     (I've not listed myself since I'm still coming up to speed on arm
>     myself.)

Ahem, this IMHO is *the* biggest and most valid point...for a couple
of years now there have been around three or four of us who care
enough to do things and a huge chunk of sarge stuff (kernels,
installer, new buildd, infrastructure, docs etc.) ended up on my
shoulders...I *think* I did OK but I need more time in the day to sort
the outstanding issues.

>   - Not having enough users listed;

This is insane...Simtec alone can say we have several thousand users
just from our dev. boards...and if some of the places Debian ARM is
running were running popcorn or getting updates from public mirrors
the admin team would be screaming at me to stop ;-). Debian on ARM
seems to be used in situations where people simply want to hide the
fact its being used.

>   - Not having info on who's supporting toolchain stuff etc;

Again this is a subset of the "enough developers thing"

>   - Only being up-to-date for a very poor 94% of the archive currently
>     and only having built a likewise poor 91% of the archive.
>     (And thus probably being next in line after m68k, which has just
>     started being ignored for testing propigation). A lot of this comes
>     down to build failures, eg perl currently fails to build on arm,
>     which is really painful for the release team.

Well yes this is unacceptable, I wasn't aware of it until the IRC
meeting either :-/ sorry. A chunk of this comes from not having an
open access machine.

>   - Requiring a lot more than two buildds to stay as current;

We have three! Not excessive at all. I believe there is some confusion
on this area. The buildd have been completely replaced with nice rack
mounted CATS boxen which are perfectly capable of building everything
thrown at them (and Phil Blundels smackdown helps out on occasion)
. They are placed in three physical locations and actively
administered. We dont *need* more than these machines in the normal
course. We do have an issue on tofee where the dynamic linker keeps
failing but debugging this is ongoing (I suspect a GCC 4 build issue)

>   - Not having sufficient buildd redundancy for when the next netwinder
>     does a halt and catch fire.

What netwinders? they have all been decommissioned (because as you say
they stopped and caught fire), and thats why we have three nice new
solid boxen. AFAIK the issue of buildd is gone, finished. We *may*
swap tofee for a 533MHz machine from the Simtec Integrated module
range if we feel we need more CPU. Simtec have been very generous with
needed hardware, indeed we may be about to do a "developer" deal which
should mean everyone with even a passing interest can afford a CATS
board. Hell if you mention your a DD now you get a hefty discount!

> Anyway, I just wanted to open this up for discussion to make sure we've
> considered all sides of the issue and aren't plowing ahead with
> recertification just because it's the Thing To Do.

No, its a very, very important thing for a huge number of users...I
will try to get one or two of our less secretive customers to say
something...ok may only introduce a few thousand user entries but they
are very firm about only using Debian stable. They love the security
and stability Debian offers them.

> I don't know whether arm will be able to meet the criteria to be
> released with etch or not. My question to you is, even assuming we can
> qualify, 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?

I have a very large motivation to ensure ARM qualifies. However help
is required...no way I can do another release without *lots* of
assistance ;-)

> Or would using testing and/or snapshots for arm deployment work well
> enough for most Debian arm users? I know that testing has been fine for
> us at ADS as the base for our Debian arm releases. I doubt there are a
> lot of people running arm on serious 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. Some people seemed
> to agree on irc that this was becoming practical now that testing is
> starting to get things like security support. Comments?

Again the stable universal releases are what drive a lot of our
customers to build systems capable of running Debian in the first
place. debian.security.org is what really clinches the deal.

> The other side of that question is whether, if Debian didn't target the
> arm port at stable, Debian testing would remain in a usable state for
> arm. Some of the current issues obviously need to be addressed anyway
> for arm to be a viable Debian architecture of any sort.

I doubt *direct* ARM Debian use would survive beyond developer use.
Using Debian as a base for hacked together solutions or perhaps as a
source code archive would become more common. I feel the drawbacks of
using the full distro would rapidly outweigh the benefits of "roll
your own" solutions.

These are my personal observations, from a tired and slightly grumpy
developer. I do hope that we can get developers interested in the port
again and as soon as the open access box comes online they can help
fix the obscene number of outstanding builds

Regards Vincent

Attachment: signature.asc
Description: Digital signature

Reply to: