Hi all,
as of today all the outstanding PRs on the Solo5 repository has been
merged, so we are in a good position to set concrete plans for the next
release (tentatively 0.3.0).
The main item I have on my list, to be done either before or immediately
after a release is #172 ("renaming ukvm to a more generic name"), and the
associated code and terminology reorganisation discussed there. I have been
putting off working on this partly becase it will touch everything in the
codebase, so it would have made rebasing the existing in-flight PRs hard
for contributors.
There are two options for how this can be done:
1) Release, freeze, rename: We cut a release now, with the code in a state
where existing features are tested and stable (well, OpenBSD is still new
and thus "experimental", but that's fine). After that there will be a
freeze period (say, ~2 weeks) during which I will work on #172.
2) Freeze, rename, release: We do the renaming first, then cut a release.
The disadvantage of option 1) is mainly for downstreams (MirageOS), since
the renaming will change the user-visible terminology for targets (ukvm ->
vt), and the goal of #172 is to get everyone (users, developers,
downstreams) on the same page terminology and code-wise.
However, even though it's "just" a rename and refactoring, after discussing
with Dan and Ricardo this week it does seem prudent to release known-good
code. I'll discuss this next week with the MirageOS core team and make a
decision then.
There is one other annoying "administrative" issue. Over the course of the
past few months I have mistakenly committed a bunch of commits to the
repository with a former employer's email address. I'd like to fix this for
legal/attribution reasons, however the only way to accomplish this is to
rewrite the history on the public Solo5 "master" branch. This will mean
that everyone's existing clones and/or outstanding PRs will need to be
manually fixed.
The freeze looks like a good (only?) opportunity to get this done with the
least amount of disruption. I'll send out a separate email about this after
investigating exactly what needs to be done and how it will break other
repositories in more detail.
-mato
