Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Subject: Re: Can we drop armhf (armv6) after v3.12?
From: spam@ipik.org
In-Reply-To: <20200528104748.4d37ede5@ncopa-desktop.copa.dup.pw>
Date: Thu, 28 May 2020 11:19:19 +0200
Cc: Alpine develmopment <~alpine/devel@lists.alpinelinux.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B10D4884-BC26-4ADE-8FBB-0AEF787E1831@ipik.org>
References: <20200528104748.4d37ede5@ncopa-desktop.copa.dup.pw>
To: Natanael Copa <ncopa@alpinelinux.org>

Dear Natanael,

While I understand supporting many platforms has a burden,
this proposal is a bit of concern as:

- PiZeroW obsolescence is not planned until Jan 2026 at earliest
https://www.raspberrypi.org/products/raspberry-pi-zero-w/
We can expect Pi foundation & quite wide community will then
stay behind it, and provide patches, for most critical components.

- PiZero is officially supported in upstream kernel, and we=E2=80=99ve =
not
seen any obsolescence notification yet (or I missed it)

- Alpine is a platform of choice for low-ressorce devices, and PiZero
is a perfect illustration of such target.

- While I do not have shipment volume info, it is expected that it
is a pretty big chunk of such tiny SBC category


Would a path with limited support for some demanding UI framework
make it easier to consider?
Many server usecase may not require such UI frameworks.

I hope Alpine will keep armhf for few major releases.
Many thanks for consideration.


> On 28 May 2020, at 10:47, Natanael Copa <ncopa@alpinelinux.org> wrote:
>=20
> Hi!
>=20
> Can we drop the armhf architecture after 3.12 release?
>=20
> It means that we will continue support armfh with 3.12 for two mor
> years, but edge and next release 3.13 will be without armhf.
>=20
> This means that we effectively drop support for Raspberry pi 1 and
> raspberry pi zero which are armv6. This is also the hardware we have
> kernel for.
>=20
> The reason is that there are increasing number of issues that are not
> fixed upstream. For example:
> https://bugreports.qt.io/browse/QTBUG-65246
>=20
> We will also need to rebuild all our 32 bit architectures from scratch
> when upgrading to musl 1.2 due to time64. It requires significant
> effort to do that and it would be nice to only need to do it for x86
> and armv7, and drop armhf.
>=20
> Are there any good reasons to why we should keep armhf?
>=20
> Are there other reasons to why we should drop it?
>=20
>=20
> -nc
>=20
> PS. This was previously been discussed for 3.10 release:
> =
https://lists.alpinelinux.org/~alpine/devel/%3C20190404112525.4b04fdeb%40n=
copa-desktop.copa.dup.pw%3E#%3CCAGP1gyPCsaHh+85g0QX-Cu40K-5Vd7xqLTV2aGiUgU=
r+RdrdFQ@mail.gmail.com%3E