Re: [Stretch] Status for architecture qualification

On 16/06/16 02:12, Hector Oron wrote:
> I have put up the classical wiki page for Stretch at:
>   https://wiki.debian.org/ArchiveQualification/Stretch
> 
> Please review and comment if required.

That page is now outdated wrt mips concerns (see below). Do we need to duplicate
the information that we already have on r.d.o/stretch/arch_qualify.html ?

>>    - s390, ppc64el and all arm ports have DSA concerns.
> 
> I understand s390x and ppc64el DSA concerns have been clarified
> in-list and those concerns are due to nature of the architecture.

Sure, that's fine.

> For the ARM ports, which have also been clarified, let me re-confirm:
>  * arm64 port has remote power and remote console available, plus
> geo-redundancy, hardware is available and there is more hardware
> coming in the pipeline. I am unsure why it is listed with multiple DSA
> concerns, that surprises me (with DSA and ARM porter hats). The port
> currently has 4 machines up, one down waiting to be replaced, in total
> 5 and more coming.

OK. I have removed the DSA concerns for arm64 from arch_qualify due to this.

>  * armhf/armel ports share hardware, we currently have 6 machines up
> with remote power and remote console (of course that being development
> boards is not so nice as server remote management goodies). Some
> machines require a button press but local admins are great and always
> happy to help.
> 
> If none steps up explaining what are DSA concerns on the ARM
> architectures, please update status requalification page dropping
> those concerns. [DSA hat on]

AIUI armhf/armel needing local admins should still be a concern, even if mild.
Ideally that wouldn't be necessary. I have updated arch_qualify to reflect that.

> I see armel has one porter listed, if more are needed, please add
> myself and Riku Voipio (armel buildd maints). [ARM hat on]
> I see arm64/armhf are covered porterwise however there should be more
> porters available if needed.

I have added you two as armel porters.

>>  * mips64el (NEW)
>>    - No DSA buildd (RT blocker)
> 
> As far as I can see mips64el is using shared builds with mipsel port
> hardware, those machines are DSA.

We now got more hardware. This is no longer a concern.

>>    - Rebuild after import not complete (RT Blocker)
> 
> Is there a list of packages that should be rebuilt?

There's just one package missing, which is being worked on. See Aurelien's mail.

>>    - Not yet in testing (due to the above).
> 
> Please let's work on getting it in testing ASAP I think the above
> blockers can be worked out quite reasonably.

Once db5.3 is rebuilt, we can enable mips64el in testing.

> While working out ArchitectureQualification/Stretch wiki page I
> believe everything is mostly fine for release, however I got a
> personal concern on powerpc architecture. Is it well maintained? Does
> it have porters? Does it have users? Does it still make sense to carry
> along?

Not sure about this one... I don't think anybody has stepped up as a porter.

> Another concern (DSA) which I have added and explained in the wiki
> page is the lack of georedundancy for the 'mips' port. Verbatim copy
> from wiki follows:
> "mips: It has 5 buildds in the same datacenter, current hardware are
> routers or development boards which makes it very difficult to ship to
> other places. The host providing redundancy (lucatelli) at UBC-ECE
> must be decomissioned ASAP, leaving the port in a situation of not
> geographic redundancy. However advanced plans exists to deploy mips
> hardware in other data centers RSN."
> 
> I'll keep you posted whenever there is progress on that area. I do not
> believe it should be a blocker for release, but we must ensure geo
> redundancy first.

That's sorted out now.

Cheers,
Emilio