What's going on?

Hi everyone. Following the high levels of engagement and enthusiasm we saw leading up to, during and after the Open Sourcing announcement, I wanted to take a moment to explain a couple of things we have bubbling away within ROOL. They aren’t ready for prime time yet but I don’t want people to start thinking we’re not moving forwards.

Development tools

At the London Show, we explained how we at ROOL recognise the cost associated with the development tools (DDE) could be seen as a further barrier to entry for new developers to engage with RISC OS. It jars with the ethos of Open Source. There has been a lot of lively debate within ROOL around what to do about it and I’m pleased to say we now have a straight-forward plan. There are two loose ends to tie up and then we will make the announcement.

Access to the source code

We are committed to migrating the RISC OS source code from its current home in a CVS repository to the far more relevant git source control system. A plan is shaping up on how this will be achieved and we’re just weighing up various costs and benefits before we think about scheduling-in the work.

This process will take in the order of a few weeks to complete and with the amounts of time we can afford to commit, it’s probably reasonable to say we’ll have sorted this out by the end of the year.

Access to the ROMs and other 5.26

We would like to update the Downloads section of our site to host updated releases of all the main bits – to reflect the fact that the stable release of RISC OS has been version-bumped from 5.24 to 5.26. The work behind this is mostly irritating faffing with various fiddly bits but it is moving forward. However, we view this as the lowest priority of the three strands of work, so it may not happen as quickly as we’d ordinarily like.

to the far more relevant git source control system

How is git “more relevant”? Is that a euphemism for “trendier”? It’s a messy design with a horrendous command line and… Is there even a RISC OS git? ;-)
Will you be hosting this yourself, or via an external site like GitHub?

Presumably “relevant” in the sense of “of contemporary interest” (to quote the OED) rather than “appropriate to what is being done”.

I found a reference or two to a RISC OS Git, but I got the impression that it doesn’t work very well. If memory serves me correctly, Steve mentioned GitLab at the show.

Now to wait for DDE news with bated breath :)

I am currently working on a converter to convert RISC OS CVS history to git. It currently consists of:

• Patches to correct the history in CVS.
• Modifications to Eric Raymond’s cvs-fast-export
• A python program to interpret the Products files.
• A bash script to run it.

It currently needs the handling of vendor branches fixing.

I also have a set of patches to to move the Dynamic dependices from the Makefiles which is a nuscience when working with git. I will send them this weekend.

Access to the ROMs and other 5.26

If NOOBS can find the RISC 5.26 ROM and firmware for the Pi can an SD card image be downloaded? If so, from what URL please?

Timothy, have you tried the classic cvs2git (based on svn2git with a cvs2svn step before)? We had good experiences in our company when moving from CVS to Git once we had sorted out the “source” (i.e. brokeness in CVS that was ignored by CVS clients, especially when branch tags were not where they should have been because someone moved the tag).

One of the biggest problems we had was the question of “encoding”. Our CVS was ISO-8859-1, and we first converted it to UTF-8 before converting it to Git (but obviously only those files that do not have a “natural” encoding or an explicitly declared encoding). Not sure what would be “correct” for RISC OS sources and how many different types of files would need to be handled.

We might find out that the Git repo will be a bit big which slows down certain operations quite a lot. Maybe some irrelevant branches can be removed in the conversion process.

Not sure what would be “correct” for RISC OS sources

They ought to be obvious – not UTF-anything…

How is git “more relevant”?

Everyone expects Git nowadays when contributing to Open Source projects. Not because Git is a glorious example of user friendliness – quite the opposite, especially the command line – but because all the tooling is “just there” and available for free. GitHub, GitLab, Bitbucket, even SourceForge. The standard Git workflow for contributions – forking, branching, pull request – is well-understood and easily integrated in a code review process (and there is free tooling here, too).

The only Git contender here is probably Mercurial, but it has lost its momentum (if it ever had it). Other systems are either considered obsolete or exotic – of course, RISC OS could choose a very exotic VCS to match the exotic nature of the OS itself. I would suggest Darcs, Bazaar or Monotone :-)

Is there even a RISC OS git? ;-)

No, but we need one anyway. For a Mercurial client, I guess it would suffice to port a recent version of Python. For Git, just port Java, and you’ll get JGit for free :-)

I’ve been more of a Mercurial fan over the years, but have had to use git a lot more for various things.

For a Mercurial client, I guess it would suffice to port a recent version of Python. For Git, just port Java, and you’ll get JGit for free :-)

That sounds like the joke about using regular expressions: “Now you have two problems.” ;-)

It might be possible to use Dulwich to access git repositories using Python on RISC OS. It provides a pure Python implementation as well as one that uses C extension modules.

No, but we need one anyway.

We need a lot of things…

Am I the only one who finds it bizarre that the sources to RISC OS may ¹ be moving to a version control system that isn’t accessible to RISC OS?

¹ Unless, of course, ROS announce a GIT utility at the same time as pointing to the repo…

Hopefully this will get us some way to building on UNIX again. At which point the availability of a git client (which needs mmap() to have decent performance) is less of an issue. :)

Am I the only one who finds it bizarre that the sources to RISC OS may be moving to a version control system that isn’t accessible to RISC OS?

I like to do everything I can on RISC OS, but I’m a pragmatist. If it helps develop RISC OS then why not?
I wonder what riscos.info’s autobuilder uses?

As mentioned in the other thread, there’s also SimpleGit.

I’d prefer a native git binary over an interpreter-based solution like Dulwich – the ROOL source tree is large enough that a slow or memory-hungry git client could become an issue, and we’ll almost certainly need to make some tweaks to the client to make it more RISC OS friendly (e.g. filetype mapping).

I wonder what riscos.info’s autobuilder uses?

The autobuilder and its recipes are stored in SVN. When the autobuilder builds a program, it can fetch the sources from a variety of places (http, ftp, svn, git, etc.) – assuming the correct tools have been installed on the host (Unix) system.

How is git “more relevant”? Is that a euphemism for “trendier”? It’s a messy design with a horrendous command line and… Is there even a RISC OS git? ;-)
Will you be hosting this yourself, or via an external site like GitHub?

I have to say I have similar feelings to Rick regarding git. I love Linux and I can see git is a great technical achievement and a very powerful system, especially for large projects. What I don’t like is the user interface, or lack of one. Instead we have no end of low level magic incantations that often bear only a passing relationship to the sort of simple, high level source control tasks a user might have expected to perform in the past.

Unfortunately this interface seems to have been evangelized as some kind of wonderful new paradigm and it looks like it’s here to stay in the open source world, for the next few years at least. So I can understand the benefits to RISC OS of adopting this. I’d much prefer GitLab over GitHub simply because I’m less than impressed by some of the behaviour going on in Redmond these days.

Then there’s also using libgit2(?) as the backend for an RO client. IIRC they like to boast that it doesn’t have any dependencies and can be built on anything.
Sounds great? I downloaded the source a couple of months back. Step 1: Use cmake… fffffff

I think the people in the next office are probably wondering why I suddenly collapsed into a fit of giggles…

I think moving to git is a positive, mainly because there are some great and accessible workflows (e.g. GitHub). I contributed so etching to a JavaScript project, and I had never used git before – I just uploaded my files with a browser, and a simple PR was created. It is very easy to read and review.

I have used Timothy Baldwin’s RISC OS tree on GitHub when browsing or searching the RISC OS sources, as the interface is so convenient.

Yes, a native client (or even just a simple uploader to GitHub/GitLab etc.) and figuring out some best practice with file types etc. Would be even better, but one step at a time!

I see no downsides.

Git cvsserver is a ready to use solution for providing access to git repository to CVS clients. It provides all the read operations and the ability to create commits.

This means the lack of a RISC OS git client will only cause problems for those who have use write access to the RISC OS CVS repository.

Git isn’t too bad, most of the issues I’ve had with it are between my ears :)

Noting that RISC OS isn’t yet the environment for it, try it out online (in a decent browser). Once you get used to it, it’s like muscle memory. Sites like http://rogerdudler.github.io/git-guide/ help an awful lot.

Then there’s also using libgit2(?) as the backend for an RO client. IIRC they like to boast that it doesn’t have any dependencies and can be built on anything.
Sounds great? I downloaded the source a couple of months back. Step 1: Use cmake… fffffff

The GCCSDK autobuilder supports cmake.

It looks like SimpleGit’s only library dependencies are libgit2 and openssl (and potentially libssh2). I can probably try throwing it at my autobuilder install tonight and see what breaks.

The GCCSDK autobuilder supports cmake.

I was sort of blocked by cmake when I tried, hope someone is successful at getting the lighter git built.
I have been working my way through the full size git and the main functional change is for online use. The git binary calls the git-remote-http binary using pairs of stdin stdout and doesn’t get anything back on stdin. My way around this would be to replace the pipe with temp files, One way pipes with the stdio.c have worked for me reliably, but I’ve never had these linux duplex pipes work.
I will forward some tidying up of the git build in a few days, at the moment it is duplicating the key two binaries instead of using symlinks or/and alias’s.
Will soft symlinks be supported by RISC OS one day? At the moment, only a unixlib program will follow a symlink.
An alias can work for both RISC OS and unixlib call, but at the moment having symlinks does highlight which are the needed binaries, and will cut the size of the package by an enormous amount.

As you say though, Jeffrey, a native solution would be best/safer.
The new native ssl will be significant. Do the current builds get done on x86 hardware, maybe it is not so important to ROOL?

libgit2 seems to build to a workable state with only minor patches required. Working on SimpleGit now (well, waiting for openssl to build).

…and SimpleGit seems to be working as well (if rather slow on an Iyonix). Now to try and tidy things up to create an autobuilder recipe.

Nice one, Jeffrey!

The new native ssl will be significant.

For porting software? Most probably not. Anything ported will rely on OpenSSL, LibreSSL, mbedTLS or GnuTLS. Very few tools and libs like curl/libcurl support “native” SSL/TLS on mainstream OSes like Windows and MacOSX, but the likelihood of supporting “native SSL” on RISC OS (which in itself is “just” a port of mbedTLS) is exactly zero.

The new updated AcornSSL with the updated HTTP fetcher is really aimed at native and homebrew RISC OS stuff, not for ported stuff.