We're throwing open the doors to our lab
Posted by Ben Avison Thu, 10 Oct 2019 12:57:00 GMT
Following a period of beta-testing by a small group of volunteers, ROOL is proud to announce that our GitLab is now accepting sign-ups for anyone wanting to contribute to developing RISC OS. Dive in, the water’s lovely and warm!
What is this all about?
Software typically goes through many versions over its lifetime, more than most other types of creative work, which makes it especially important to record what changed when and why. Step forward a tool called a version control system.
The simplest version control system might be avoiding conflicting changes by different authors by having a fluffy toy: the developer who holds the toy is the only one allowed to edit the component. Clearly that only works when everyone’s in the same room.
CC-BY PXHere
In 1996 Acorn selected a system called CVS for source control to replace some earlier in house efforts, and the fluffy toy. ROOL continued to use CVS given some tie-in utility scripts that building RISC OS depended up, that is until Git came along.
The move to Git
While several other source control systems have come (and gone!) since 1996, one called Git in particular has come to dominance, with estimates varying between 70%-90% usage amongst both open and closed source projects.
ROOL have now converted the RISC OS code base, including the entire history of changes, into a collection of Git repositories, one for each component. That involved chewing through
- 2,589,725 lines of C code spread over 7,115 files
- 1,041,241 lines of ARM assembler spread over 2,361 files
- 13,735 other supporting files
- 535 individual components
- 106,464 historical commits from 69 authors
NASA scientist Margaret Hamilton didn’t even get close with her 420,837 lines of code used for Apollo – we can eclipse that by printing out RISC OS
We have also set up a GitLab server which gives a browser-based view of everything. The Git repositories are then hosted on the GitLab part of our website.
More eyes on the future
One of the key differences with GitLab is that it encourages a much more collaborative nature for submissions. Previously there could be bottlenecks waiting for someone with the right skillset to be free when submitted via email, while a privileged few who had direct access could make conflicting changes in the meantime.
With GitLab, proposed changes are publicly visible. You can get a sneak preview of the changes that are in store before they’ve been accepted.
With visibility to many more eyes the review process should be more thorough, and hopefully quicker, encouraging
- better code quality – more readable and maintainable, with better documentation, making future development and bug fixing faster and easier
- the identification and remediation of side-effects that may not have occurred to the original author
- a greater sharing of knowledge and responsibility, avoiding “guruisation” of sections of the source tree
- catching bugs, security issues or license violations before they end up being distributed to end users
As a rule of thumb, you should try to get involved in reviewing at least as many of other people’s merge requests as you intend to raise yourself. The more you help to review the faster the wheels turn – while we’ll always try to look over any that are languishing, the intent is to reduce the bottleneck of ROOL as a reviewer by help from a larger group of individuals.
We’ve barely scratched the surface
By hosting the RISC OS sources on our own GitLab installation we’ve been able to make a few customisations that wouldn’t be possible if a 3rd party hosting site such as GitHub, such as syntax colouring ARM assembler.
One feature we’ve not yet set up is called Continuous Integration where code submissions can be compiled by GitLab (and potentially even tested) before they are accepted. This could also make binaries for each applicable target platform available for reviewers to test on real hardware.
There are some technical challenges to get that all to work, but we’re sure you’ll agree it will be worth it in the end!
Getting started as a developer
We’ve put together a cheat sheet for some of the more likely setups showing how a typical submission flows.
There’s also a bounty collecting donations to trigger a bounty hunter to work on bringing RISC OS a mature Git client of comparative speed to those other OS’ enjoy. This should allow us to simplify the transfer steps in our cheat sheet some more too.
Tell me more!
For a more in-depth discussion of what this all means please read this article.
When will RISC OS 5.26 be released please? The version on the downloads page is still 5.24, over a year after it was made available on NOOBS but kept secret on the downloads page.
You may in any case have one individual filling in as the head of family IT, however with voice input, everybody can connect with the home without managing log-ins, consents or finding the correct telephone. By : https://www.ukessaywriters.co.uk/dissertation-writing-service.php
Great news! Like Chris Hall, I too am wondering when the planned 5.26 release will be. :-)