Many years ago I was using fossil for OpenBSD development to manage my patches.
Around that time I tried to import the entire OpenBSD src repository into fossil, by importing the CVS-to-git conversion of src, as published on Github. I was following the official git->fossil migration guide. I left this running for a week (or two?) at which point the fossil git loader was loading OpenBSD commits from somewhere around the 2000s. At that point I stopped the process. Performance might be better today, I don't know. And perhaps post-conversion run-time performance is much better, but I never got that far. Anyone can try to reproduce these results by running the same conversion today.
I don't think I ever talked about my attempts with fossil to anyone at the time. But I recall the topic coming up somewhere when the Game of Trees project became public, and someone suggested I should be using fossil instead.
I am now using Game of Trees for all my OpenBSD development work and I am happy with it.
Git is not insufficient. For various reasons, Git is not a good match for what OpenBSD needs. OpenBSD needs an implementation that uses privsep, pledge, unveil, fits the mindset needed for Theo to accept running it on his own infrastructure, doesn't carry more baggage than necessary, and is a joy and easy to work on for OpenBSD developers independently from third parties. So the options were forking Git or writing something else, and I chose to do the latter.
Hi, I am the Game of Trees project founder and main author of the code.
If there is anyone here who would be interested in seeing this project
advance faster and has funding available, please talk to me.
I am a freelancer with an EU VAT ID.
Progress since the beginning in 2017 has been steady but slower than I would like.
I have occasionally applied to various open source funds (prototype fund,
NGI zero, and the like) but was never lucky enough to get funds allocated
(which is fair: many other great projects are being funded instead, so I am
not bitter about this).
And I don't want to bother the OpenBSD Foundation since they are already partly
funding unrelated work I am doing in the OpenBSD wifi drivers and 802.11 stack.
I also believe that the ability to run this alternative Git client on any nix,
and the alternative Git server on OpenBSD (though there are plans to port the
server to any nix as well) can be useful for many communities and organizations beyond OpenBSD.
Some things I would like to work on in particular are:
- SHA256 object ID support, enabled by default, with repositories running
either SHA256 or SHA1, without the ability to mix different hashes in the same
repository. The server could offer a read-only repositories converted
to SHA1 for legacy clients which do not support SHA256. Git itself does
already support SHA256 so this won't break compatibility with regular Git clients. Though it might not be possible (yet?) to push SHA256 repositories to many hosting sites but that is not Git's fault.
- Server-side "trivial-rebasing" of changes, such that clients could push
changes to servers without having to fetch first, provided pushed changes
can be merged tree-wise, ie. without any file content clashes or unclean
additions/deletions of files.
- Performance improvements; Got currently spanws one privsep child process per pack
file on disk, cycling children in and out as needed when there are too many
pack files. This can cause a lot of forking during random access across the
entire history, which occurs when computing deltas while packing.
Small pack files should be stored in memory instead, and each child process
should be able to handle multiple packs to reduce the amount of forking.
You can skim the man pages to see all the work that has already
been done: https://gameoftrees.org/manual.html
And of course you can read the source code; see the web site for details.
> I would have worked on the same project in the summer even if I was not getting paid
Yes, this is exactly what GSoC can be good for. Ideally, it allows people like you to spend time doing what they love doing instead of working for crappy startups.
The good (and fun!) experiences I had as a mentor all shared this element.
What I think is unnatural is the situation where the student is being paid, and where the mentor has a formal responsibility for the student and acts as the person who ranks the student and thus decides upon their salary (fail the student -> no money).
In a normal situation, new contributors show up and are self-motivated, and receive guidance from others so that over time they become equals. The mentor's role is spread among several people, and it is informal and temporary.
There is no money involved.
Many (not all!) GSoC students do not experience what the normal situation in open source feels like.
I am happy that your student is an open source enthusiast and got a job in open source. That is great.
I have seen this kind of good experience, but also more disappointing ones. In one case, a student simply disappeared after the first payment (in the middle of the summer) had been issued.
For this particular open source project GSoC brings no advantage to the table (yes, it may be great for other projects).
OpenBSD does not need GSoC to attract contributors.
The project gets a good amount of new contributors on a regular basis, and they get onboarded quickly without
causing much distraction, if any.
The mentor/student relationship is atypical for open source projects which are used to operating as a community of equal peers.
Mentoring students who expect to be mentored takes a lot of time, and the vast majority of them don't come back. In my experience money
is a key incentive for students in GSoC and that makes it hard to keep them as volunteers. Unless you are very lucky as a mentor and pick a student who turns out to be an open source enthusiast, they won't actually care about your project in the long term. And there is no way of knowing that during the application process. Unless in special cases where you already know the student, as I did in one instance, but that's an exception.
(Speaking as an OpenBSD dev, and as a former mentor of several GSoC students, over several years, at the Apache Software Foundation).
+1 -- This is the one and only problem I have to regularly help my non-technical Ubuntu friends (and their friends) with. Every few months they cannot install updates anymore because their /boot fills up and apt fails to install a new kernel package.
The simplest fix would probably be to make /boot large enough by default (in the order of 10GB or 20GB or so -- the current size is 512MB IIRC).
A better fix would be to purge old unused kernels automatically but as far as I understand there were some difficult edge cases around that.
These look nice but they focus on the physical layer.
Do you happen to know any useful English literature that covers the MAC layer of modern wifi standards (n, ac, ax)?
Apart from the 802.11 standards, of course.
Please don't remove your post. Pointing out these issues is very important, and making one donation should not indemnify people who behave in this way.
They took much more than they have given (which the source code licence allows them to do, even if it's morally wrong). Claiming they never gave anything at all is incorrect.
The photos are all from the area around Calgary, where some of the initial ideas were born during an OpenBSD hackathon. IIRC we disabled Latin1 support during this hackathon.
While giving this talk in Belgrade, Ingo apologized he didn't have photos from a Belgrade hike yet so he used the Calgary ones instead.
Around that time I tried to import the entire OpenBSD src repository into fossil, by importing the CVS-to-git conversion of src, as published on Github. I was following the official git->fossil migration guide. I left this running for a week (or two?) at which point the fossil git loader was loading OpenBSD commits from somewhere around the 2000s. At that point I stopped the process. Performance might be better today, I don't know. And perhaps post-conversion run-time performance is much better, but I never got that far. Anyone can try to reproduce these results by running the same conversion today.
I don't think I ever talked about my attempts with fossil to anyone at the time. But I recall the topic coming up somewhere when the Game of Trees project became public, and someone suggested I should be using fossil instead.
I am now using Game of Trees for all my OpenBSD development work and I am happy with it.