Take notes here in the session please!

armel - started at 2007, thinking about dropping it in near future.
	Only Debian still supports armv4t with soft float amongst common
	distributions. Still kernel support and gcc. Issues arising with
	packages which do not support pre-ARMv7. (nodeJS)
	Jessie LTS might not cover armel, Wheezy LTS does.
	New hardware designs are around, targeting the armel chips but
	would still need vendor kernel.
	NAS use cases for armel.
	* Partial armel architecture?
		No clear plan for how to create and maintain a partial,
		let alone releasing.
		Drop desktop tasks and dependencies.
		Keep web server and mail server - trivial in comparison.
		Lack of video use cases.
		Headless partial arch for armel?
		Build daemons would be a problem, so let armhf buildds do
		the builds. Can't do that on ARMv8 (which can do armhf).
		Kernel helper to emulate barriers but hardware support can
		be lacking on ARMv8 hardware.
	* Update from v4t to v5tel and go headless?
		No kernel support for exclusive v4t.
		Openmoko would be ruled out of this partial arch.
		Kirkwood and Orion can be maintained.
	openssl and other updates would be useful within stretch.
	Propose to keep in stretch and go to v5tel partial arch after stretch.
	Not clear how much work it is.
		Packages would have to specify armel or it will not build.
	Volunteers?
		zumbi & bdale able to help.
	Less effort to keep stretch LTS for armel and then drop armel entirely.
	Stretch end of life 2020 - actually sounds like enough, considering
	the performance of the existing hardware.
	Maybe consider adopting partial arch *if* others do the work to create
	it for their own use case.
	Supporting armel in Stretch LTS depends on funding or external labour.
armhf - v7 and v8 are the volume consumption from ARM. Some have made v7 without
	floating point. No software support from Debian (or anyone else).
	Kernel support via ARMMP and armmp-lpae. Huge set of devices now
	and still in development.
	EFI shim for boot services with U-Boot. Painful for power management
	or to set EFI variables. Interface with Grub - UBoot config changes
	are unknown at this stage.
arm64 - All good. Real hardware available to buy, more coming. Move buildds
	over to ARMv8 hardware. Seattle has replaced a Juno which pleases
	DSA. Single kernel with DTB or ACPI. HP can provide a hosted solution
	for their own hardware for use with Debian. Mobile ARMv8 hardware is
	problematic - concentrate on the server hardware. Linaro has a co-lo
	in Austin based on Mustang devices. Cambridge lab has AMD ARMv8
	hardware. Buying ARMv8 box is starting to be practical.
	Cello or SoftIron 1000 $600.
	96boards are not a standard form factor. Marvell board is ATX form
	factor - due second half of 2016. Softiron 1000 does not have PCI.
	Pine64 is a vendor kernel until the 4.10 kernel, hopefully. (Quad
	core A53. $29)
	ci.debian.net needs more ARMv8 hardware - increase to 10.
	No root CA for ARM UEFI. HP doing their own.

boards - http://www.96boards.org/
         http://softiron.co.uk/

Neon extensions:
	Building on the porterbox, buildd does not.
	Difference in the hardware between buildd and porterbox.
	Need to do runtime detection, same as for SSE, instead of
	compile time detection.
	runtime linker can check the hardware capabilities.
	Neon for armhf was omitted due to Tegra2.

Big endian - general purpose distributions only interested in little endian.
	some people are configuring it differently.

ILP32 port - general purpose could care depending on funding.
	(big endian and little endian)
	Not for Debian.