Providing fixes for RISC OS source code - how to do?

I’m currently working on a project (I don’t want to say what it is until it progresses further, as din’t want to risk the whole vapourware thing!). However, I have a question:

Is there a way to discuss possible fixes / updates for the RISC OS source code? I know we have the ‘Code Review’ forum, and the git repository, but assume git is locked (otherwise too many cooks spoil the broth!), and don’t want to spam ‘Code Review’ with lots of small fixes, or discussions of possible extensions to the code?

As an example, I currently use a modified version of BBC BASIC, which has a number of additional options added; a particularly useful option is that I can set the assembler so that, upon encountering a negative immediate operand, it automatically checks whether the operand can be negated or inverted, and if so, it can switch ADD to SUB, MOV to MVN or vice versa, automatically negate (or invert) the immediate operand, and assemble the instruction; this is particularly in assembly code that uses a workspace pointer that has offsets above and below the pointer, especially when changing stuff that results in offsets changing sign between compilations!

I have also fixed a bug I found in the assembler code.

Anyway, is there a generally agreed way to go about discussing the above for consideration re: RISC OS source code? Given I have a good few useful additions / fixes, but many are not closely related, and would spam the ‘Code Review’ forum if I posted each one there?

Hi Tymaja,

Fixing a bug in the assembler sounds like a great place to start. Please e-mail code@riscosopen.org asking for an account on the GitLab (see here). You’ll then be able (after it’s set up) to make your merge request. You could also then if you wanted put up your BASIC with extra options as a personal project for people to see.

Deffo email ROOL to get yourself an account on their GitLab instance. That’s the simplest way to be able to easily clone and edit the code. You can then write-up a merge request with your changes.

Looking at the current pile of merge requests, I wonder if some of them need assistance. The descriptions are not always clear (background info, reasonings etc.) and it would make it much easier for people to test out if the component in question also had a build provided (not always feasible, I know).

I guess you could do without the ROOL account, and just work in your local git. And even push the changes elsewhere, like GitHub. But it seems that the preferred way to get something to become part of the OS is to create a merge request on ROOL’s GitLab. Makes sense, really.