I'm maintaining it for the foreseeable future. The new Linux Kernel is building for 15.0 right now, actually.
I just upgraded my colo'd 32bit ARM box to 15.0 this week, and it'll be running that for probably a year at least. Maintaining the stable releases is ok - it's not particularly laborious.

I also been thinking about Slackware ARM 14.2, especially since the Kernel is now EOL. From a security PoV it's pertinent to move off that or patch it yourself; but if you don't mind about that (e.g. if it's an internal server, not exposed to many or any attack vectors), and would appreciate updates for the other packages, let me know.

I was also just thinking about how much time has now been released for Slackware forward development: the system integration tests on 32bit ARM took over 8 hours.
If something is broken, I have to fix it and run it again. This delays releases by up to 2 days, minimum.
The Kernel takes just over 7 hours to build, at which point I'd test it on all of the supported Hardware Models and every 2-3 Kernel upgrades I'll test the installer (but not on all Hardware Models, if nothing platform-specific had changed). The installation takes about 2 hours and driving the installer is manual. Obviously I don't sit there staring at it, but I do have to drop in and out of it.

The amount of effort required and attention to detail is one of the reasons (I think) why there aren't many issues raised against Slackware ARM, and is why Slackware AArch64 isn't out yet. I'd rather arrive later, or reduce the scope of hardware coverage to maintain consistency and high standards and be sustainably supported. Fortunately I have a degree of visibility into the Slackware pipeline, so I'm able to navigate Slackware ARM and dodge some of the bullets. If I didn't have that, there'd be hardly any releases or the quality would be pretty poor.

I cannot emphasise how slow the 32bit hardware is to develop/build on - even using distcc to x86s. The OS has to be built on the platform for which it's intended/targetted. This is because some packages detect CPU features at run time, and configure the package according to the spec of the build machine. I had this problem on 14.2 for a while, where I thought it'd be a wonderful idea to switch the master build machine from armv5 (the target) to armv7 to achieve performance gains. Some of the packages (Firefox and perhaps mplayer?) and even mozjs crashed on armv5 due to containing instructions for armv7. There probably are ways to mitigate this type of thing (and at the start of the port I had a different problem but similar symptoms, where two particular instructions caused crashes on the StrongARM RiscPC, so I had some code to detect them), but such mitigations requires maintenance and in the end it's easier (albeit slower) to build on the base architecture, as I have done ever since.

The RockPro64's literally twice the speed, which means I can achieve so much more in such a short period of time and it's more fun for me! :-)

3 members found this post helpful.

Well, ya know-- that's kinda my point. You can just run 32-bit software on 64-bit hardware. And since the 64-bit hardware is faster-- that will solve that problem (I mean-- if you were actually considering maintaining only a 32-bit port; clearly, you have moved on already lol). What you can't do is go the other way around.

Yeah-- I was afraid of that. The nice thing about your Slackware ARM suite is that it works as expected (basically identical to Slackware x86). I'll probably struggle to build common packages like Qemu, Abiword, etc for Bonslack. Although, I do plan on trying those types of things (out of curiosity). I don't mind working a little bit to build a package for a slightly screwy Slackware system. So-- I dunno, this might be an okay option for me. I guess I'll find out. D:

Much appreciated. Thanks for that.

No, I most certainly do not. I'm pretty ignorant about that. I'm sure I'm not grasping the entire tradeoff (from your point of view).

I hope you never do. But there are people who are paying the price and some consideration and awareness wouldn't go amiss.

An official announcement that -current has been dropped for armv7 on the Slackware ARM website would be a good idea.

1 members found this post helpful.

I suggest that what people do is suspend their donations to the project for a while to purchase new hardware, if that's a concern.
The hardware isn't exactly expensive and (I suppose) that the peripherals such as storage can be re-used - apart from the large-form SD cards, all of my stuff has been reused even down to the USB>Serial adapters.

Hardware that is greater than the baseline for the architecture cannot be used for build machines, for the reason I already stated.