From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Time is running out for 32-bit ARM Date: Sun, 14 Aug 2022 17:29:17 +0100 Message-ID: In-Reply-To: <6D4DF854-CC45-410D-9F8B-9FB641666044@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8421674211635911621==" List-Id: --===============8421674211635911621== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello everyone, So since we had a good week of silence on this, I think it is time to come to= a decision. I had a conversation with Arne today to check on the last few things I needed= to know and together (and based on opinions voiced by others and the facts) = we have made the decision to retire support for armv6l by Feb 28 2023. That date has been chosen as a compromise between shutting it down sooner rat= her than later, and giving people enough time to migrate away. It is a little= bit over 6 months which should be enough time to find some new hardware for = the people affected. There is now officially nobody in the group of developers who wants to keep t= his architecture alive, and I think it is the best way to give it another six= months. I will submit a patch to show a warning and in early February will submit a p= atch that removes any extra code or quirks that we have implemented for this = architecture. Best, -Michael > On 6 Aug 2022, at 16:31, Michael Tremer wrote: >=20 > Hello, >=20 >> On 6 Aug 2022, at 13:40, Adolf Belka wrote: >>=20 >> Hi All, >>=20 >> Michael's suggested approach sounds fine to me. However, like Peter, I don= 't use any arm machines for IPFire so I don't have any impact personally. >>=20 >> Hopefully there will be some arm users that are on the dev mailing list th= at will also provide input. >=20 > That would be great indeed. If not, I will also take that as answer. >=20 >>=20 >> Regards, >> Adolf. >>=20 >>=20 >> On 06/08/2022 14:24, Michael Tremer wrote: >>> Hello all, >>>=20 >>> Thank you for picking this up on the list. >>>=20 >>> I would like to make the following proposal: >>>=20 >>> * We discontinue building for armv6l on May 31st 2023 - in a little less = than a year >>> * We keep hosting the packages for another three months and will remove t= hem from the servers after that >>>=20 >>> This is based on the following: >>>=20 >>> * As of today, have 0.98% of our user base on armv6l >>> * This used to be 1.69% on Jan 1st, 2021 and 1.67% on Jan 1st, 2022. >>>=20 >>> There is definitely a decline in the usage of that architecture and it is= of course incredibly small anyways. With all the extra work and workarounds = that we have in the code base here, the days and weeks that is going into it,= this has surpassed the threshold where there is no growing or steady user ba= se any more. >>>=20 >>> Having said that, aarch64 (as of today) only has 1.29% of our users. Not = particularly a lot, but it has been steadily growing. Fingers crossed that it= will gain more momentum in the future. >>>=20 >>> Why would we not discontinue this now? I personally feel that I would lik= e to give people decent time to migrate away from this. Right now, we have lo= ts of supply issues, it is already mid-August, which would result in about th= ree months until EOL. Not that this would offend a large number of users, but= I don=E2=80=99t think that we should make life too much more complicated for= anyone than it has to be. >>>=20 >>> We still have a running distribution that does not have any significant p= roblems on armv6l compared to the other architectures. It costs us build time= s - yes. It might cost us some extra development time - yes. But this is what= we have signed up for when we adopted this architecture. So we have to bear = some responsibility. >>>=20 >>> -Michael >>>=20 >>>> On 2 Aug 2022, at 11:08, Peter M=C3=BCller = wrote: >>>>=20 >>>> Hello *, >>>>=20 >>>> in January [1], we already discussed the situation of 32-bit ARM, and se= ttled on >>>> demoting this architecture as "legacy" on [2], and advising people from = buying new >>>> 32-bit ARM hardware in the wiki. >>>>=20 >>>> To some extends, this architecture shares a similar fate than 32-bit Int= el did: >>>> Security features are not backported to it, maintenance requires a lot o= f effort >>>> due to missing upstream support, hardware base is diminishing, and its I= PFire >>>> userbase does not justify the resources required for keeping the distrib= ution >>>> reasonably maintained on this architecture. >>>>=20 >>>> The other night, we have therefore agreed on putting an end to IPFire su= pport for >>>> 32-bit ARM, and take the question of the anticipated timeframe to this m= ailing list. >>>> [3] >>>>=20 >>>> At the time of writing, Fireinfo reports 0.94% of all IPFire installatio= ns to run >>>> on supported 32-bit ARM devices, to give you a figure. [4] >>>>=20 >>>> Personally, since these devices are unlikely to run in enterprises or ot= her critical >>>> environments, I would be fine with announcing EOL for 32-bit ARM at the = end of >>>> this year. However, as I am not running any affected IPFire installation= s, my >>>> opinion is biased - let's hear yours. :-) >>>>=20 >>>> Thanks in advance for your reply, and best regards, >>>> Peter M=C3=BCller >>>>=20 >>>> [1] https://wiki.ipfire.org/devel/telco/2022-01-03 >>>> [2] https://www.ipfire.org/download >>>> [3] https://wiki.ipfire.org/devel/telco/2022-08-01 >>>> [4] https://fireinfo.ipfire.org/ >>=20 >> --=20 >> Sent from my laptop >>=20 >=20 --===============8421674211635911621==--