What I have been up to in April

[Byron]

(you are reading an email sent out to sponsors previously. Lots of formatting and links got lost unfortunately)

---

Hi everyone,

I am glad that you are there and would like to share how your sponsorship helped me to develop the software you appreciate.

This month was all about clearing the slate and ramping up focus time to speed up gitoxide development.

Clearing the slate

The past 7 months I didn't manage to touch a computer for more than an hour or two, often times I wouldn't get to do anything productive easier - it has been very interesting times. That did leave its mark as my various OSS projects had their issues and sometimes PR pile up.

google-apis-rs has seen the most notable development as the project is now officially in maintenance mode with no open issues. It also gained async support and all API and CLI crates have been republished as v2.0. This should help to keep it useful and meaningful for a little longer, while actively promoting and pointing towards the next generation of these crates which aren't maintained by me.

git-python is seeing a lot of issues these days and I process them as fast as I can in a way that encourages contributions.

stdarch took a good chunk of my time, and maybe it's even a little obsessive as I admit that PR was only done only to eventually speed up ARM/aarch64 Sha1 implementations - the current one is about half the speed of what git can do which hits the indexing phase quite heavily.

Ramping up

Thanks to some data about my day I noticed that I spend a lot of time with tasks that probably are better done by someone else, at least to some extend. And that's how it happened that from April we have a lot of help for housekeeping and childcare, freeing up valuable time for software development.

Gitoxide

Right now I put everything into finding a good way to build packs. There are plenty of considerations to at least support at some point, so progress there has been relatively slow due to a whole lot of experimentation and refactoring done in the course of it.

However, it led to a considerably cleaner code base, here are the highlights:

ObjectId and oid now handle like String and str
git_odb::loose::Object was removed in favor of the newly named git_odb::data::Object. This allows to provide new traits for getting objects from a database to be used in core algorithms that take objects as input.
first traversal of the commit graph (for use as input for generating packs)
more intuitive structure and names for decoded git objects - previously there was name duplication for various kinds of objects between the git-object and the git-odb crates, leading to a lot of potential for confusion.
The progress of pack generation can be controlled from the outside despite the code be synchronous, making it easier to adopt in async contexts. This will be the case, for instance, when generating packs on the server side.
The next step is to put all the pieces together to validate they truly are working as expected, trying to get the breadth of the operation ready first. All that will validate the API as is which should get filled in along the way to finally generate some of these pesky packs.

It's great fun to see, once again, how Rust forces one to improve overall code quality so using the APIs start to feel right.

Goals for the next month

I really can't wait to finally produce some packs and, of course, measure performance to see how fast it can go with zlib-ng to stream massive amounts of objects at lowest latency, without delta-compression at first.

Cheers,
Sebastian

PS: Detailed timesheets can be found here