ROM development

At present the latest ‘bleeding edge’ daily build rom is available which necessarily contains many mature and developed modules plus a few that are being gradually tinkered with and improved. This means that the daily build always seems to contain some bits (not identified) that don’t yet work correctly. Also available is the stable 5.24 rom but this is from December 2018.

It is a great pity that there are no ‘snapshots’ of roms where tinkering on certain modules is complete and has not yet started on some others. A ‘thought to be good’ rom with a note of which modules have been updated recently (and thus require testing) and those that appear to be fairly stable (perhaps with one or two known ‘issues’ stated).

This would encourage users to download them and try them and know which modules are ‘recent’ to help focus testing.

Given infinite resource, the present system of identifying stable releases would be sufficient and no user testing would be required.

The ‘thought to be good’ rom images would not change day to day but the associated ‘help text’ could draw attention to bug tickets as issues were discovered.

This would much better use of the scarce resource for testing.

Not a new idea but a very good suggestion.

I still ocaissionally use a couple of old, but still useful, SD cards which are marked as RC8.

Perhaps, we could have a new RC series. (particularly for the Pi4?)

My main build is stiil a build which Colin produced in May 2018 to cure the outstanding keyboard repeat issues in 5.24

Just release a stable rom more often.

I am not sure I see the issue.

Stable ROMs are available from ROOL and the likes of R-Comp.

For those who like to play with fire and understand the risks, then daily ROMs or various branches of source code are available.

I presume there is nothing stopping someone sifting through the daily builds (or making their own) and publishing their own?

I think ROOL are doing enough. Perhaps even sides like the special Pi image and Pico have shown that resources limited.

John S – not really sure why you don’t use the RISC OS Direct build as your main choice – it is intended for that purpose. An official/formal 2020 release for Pi owners that fixes many of the outstanding issues, supplied under the Apache Licence with many additional features included in the disc image. You can use just the ROM, or benefit from the whole kit.

It is intended to replace the likes of the “RC” series, and (hopefully) supersede “RISC OS Pi” (not sure who official maintainer of this is, so don’t want to tread on toes). It was also supplied to ROOL for them to host here too, but I suspect time has prevented that happening just yet.

I very much appreciate all the work which ROOL are doing.

However, I think that the latest stable ROM available from ROOL is 5.24/5.26 over two years ago and there has been a lot of very interesting (and, I am sure, useful) work done since.

I have no idea how to build RO myself and stabbing in the dark with no particular nightly build sounds a bit hit and miss.

In my case, I would very much like to look at some of the up-to-date work on networking and the Pi4. Just a pointer from somebody saying ‘we think this build’ is worth a look would be worthwhile.

It does not need to be as formal as the old Release Candidates, but I see no harm in a numbering system that we could all relate to.

However, I think that the latest stable ROM available from ROOL is 5.24/5.26 over two years ago and there has been a lot of very interesting (and, I am sure, useful) work done since.

The stable release cycle is two-yearly, which given the amount of grief seems to be involved in getting every different hardware platform to test and feed back (look at the stable build status page), doesn’t seem unreasonable. There’s also the small matter that stable releases come with a new printed User Guide, so you don’t want them too often.

Had things not suddenly gone a bit weird with the world, 5.28 was due to have been released at a computer show somewhere in Yorkshire a fortnight ago. I would imagine that a release is still on the cards: you can see how they’re getting on here.

Just a pointer from somebody saying ‘we think this build’ is worth a look would be worthwhile.

That still sounds like a lot of work, and responsibility, for “somebody”. I can only imagine the flack from the armchair experts if they got it wrong.

I have a copy of RPCEmu on the PC that I can stick nightly builds into. If it doesn’t work out, the disc-based nature of the emulator makes it easy to back out and try again. Equally, I can’t remember when I last had to do that. At present, 5.27 from the weekend of the Wakefield Show that wasn’t is behaving very nicely.

Or, as Andrew says, stick Direct on your Pi.

I am not sure I see the issue.

Stable ROMs are available from ROOL and the likes of R-Comp.

For those who like to play with fire and understand the risks, then daily ROMs or various branches of source code are available.

There are many more users that could help the testing process if there was a rom to download that excluded the ‘new feature 2’ work just starting but included stuff that was ‘fairly good’ but not fully stable that had been started a few months ago. In other words a rom that is different to any of the daily builds (i.e. not a snapshot in time) that is updated on occasion after those who play with fire have played a bit with a new feature.

That takes advantage of the modular nature of the rom by holding back (in such a rom) the first steps of development of a new feature to focus on testing of things that are working but possibly buggy.

The stable release cycle is two-yearly, which given the amount of grief seems to be involved in getting every different hardware platform to test and feed back (look at the stable build status page), doesn’t seem unreasonable.

I agree.

This would much better use of the scarce resource for testing.

Aren’t we the testers, and the devs are the scarce ones?

Aren’t we the testers

It is difficult to know what has changed.

John S – not really sure why you don’t use the RISC OS Direct build as your main choice.

Because it means going back to writing partitioned SD cards again. I gave up that game a long time ago.

It is difficult to know what has changed.

True. As suggested earlier, a text file with the ROM, that just had the basic details of what modules / applications have changed would be useful.

Can git do this automatically?

I try out the latest test builds on all of my machines with the exception of my ARMX6, which is an R-Comp build.

The Iyonix, till the release of a new stable release, is soft load.

The Titanium zip has a soft load ROM to try out before flashing the new ROM onto the machine.

As for the Raspberry Pi. I have a spare Raspberry Pi 3B# with two cards. If the new ROM gives problems, then I swap the cards and exchange the bad ROM and HardDrive4 for the previous working version from my back ups.

ROOL have made testing the latest builds as easy as possible so I really don’t see what there is to carp on about.

1. 36 quid on Amazon.

I think people under estimate the work that is required to give a build a status.

What would happen if someone said this build is OK , with these features, and a user tries it and manages to lose their system/hard drive contnets.

They are test builds and I don’t think it is beyond us as users to help out a bit and test them and feedback issues.

Yes it would be good to get quicker formal builds but at the end of the day I’d rather the developers concentrate on delivering features than spending countless time going through interim ratifications after all the likes of RComp/RISCSDev supply “ratified” interim builds.

As Ron says Softloads are the way to go if you are nervous.