Heptapod News, end of summer
Many things happened this summer since the end of the Bitbucket era and the Heptapod 0.15.0 release, so it's well worth an account.
We'll begin with a recap of advances from July on developer tools, then report on the first Heptapod sprint and end with current progress towards the future Heptapod 0.16.0.
Building a development community
This is more of a general trend than breaking news.
Before the summer, our main priority had to be catching up to current GitLab versions. This meant we were on very fast moving ground, making it especially hard to capitalize on development tools and onboard new contributors.
With the Heptapod 0.14.0 release, we were finally close enough to upstream that it made sense to work on the development setup and I could envision my personal priorities to change, focusing more on foundational work and enabling other contributors.
This led in July to the first publication of the Heptapod Development Kit (HDK) and the organization of the first Heptapod sprint, which was on July 31th, half a week before my vacation time and just a day after the 0.15.0 release.
First Heptapod sprint, in virtual
The plan
My original idea was to focus on documentation and user feedback, because I thought that it would be very useful and wouldn't require a fully working developer setup. Also, these matters tend to be easy to release quickly, being at the top of the dependency chain as they are.
The sprint was organized on a rather short notice (about 3 weeks) and was of course to be held remotely, given the current pandemic situation. So we called it a virtual sprint (vsprint for short) and decided it would be a single day, centered on the European time zone. After a poll, we settled for Friday, July 31th.
How it went
It turned out a bit differently than I expected, and that's very fine!
First, the attendees were more motivated by working on the user feedback than on the builtin documentation, with the main target of replacing messages and instructions meant for Git with Mercurial ones.
Since Heptapod actually wants to support eventually both Git and Mercurial, in many cases, the changes went a bit deeper than changing string constants.
Second, Elouan and Sushil were strongly interested into setting up a full HDK for themselves, which means they are now ready to contribute also in more central areas of Heptapod.
Meanwhile, Antoine decided to work on the HAML templates directly in the Docker image, which led to his writing a blog post about how to do so efficiently.
Raphaël already had a working HDK that allowed him to be productive right away and to help the others.
Conclusion
Overall, the day wasn't very crowded, but that was a good start.
On the concrete site of things, we end up with a better user experience, with many messages adapted for Mercurial in Heptapod 0.15.1, that was released a few days later.
To have two more fully equipped developers was a very good surprise, and is very much in line with our goals of building a community.
I think we should definitely have more such vsprints, perhaps every two months? That would place the next one at the end of September.
The future Heptapod 0.16
After I got back from vacation, I quickly declared Heptapod 0.15 to be the new stable series (HDK users should upgrade), and produced security update 0.15.2.
Then, development started again for the future 0.16 with some foundational tasks. We are aiming at a release candidate next week.
Version bumps in the future Heptapod 0.16
Upstream GitLab was updated to 13.3, released on August 22nd. Thanks to Heptapod 0.15.0 being only one minor release behind upstream, we were for once not so much in a hurry, but time flows fast anyway: GitLab 13.1 will reach its end of life on September 22th.
Mercurial went from 5.4 to 5.5. There's not much to be said here, except that of course that also required updating hg-evolve to 10.0.1 and hg-git to 0.9.0.
Solving the frontend assets packaging issue
This is one of the two main pieces that we are currently missing before we can tag Heptapod 1.0, the other being the Mercurial native mode.
In short, we've never been able to ship modifications to GitLab's front end, except for classical HAML templates. Suffice to say here that there are many possible developments that are blocked because of this. For more details, see heptapod#338.
There's been good progress on that front, with early experiments showing that the minimal approach outlined in heptapod#338 is the way to go. This is also a logical step towards the long term goal of providing fully operational Omnibus packages.
Mercurial native mode
This is the long term subject to expose Mercurial changesets to GitLab directly, instead of relying on an auxiliary Git repository. This should be provided by integration of HGitaly project.
With all the version bumps, and the packaging overhaul taking priority, we didn't have much progress so far on that front since the days of Heptapod 0.14. At this time, a fair amount of development happened on the HGitaly project, but wasn't integrated.
We're currently about to resume work on integration of HGitaly in Heptapod this week. That being said, it's probable that the actual option will appear only after the Heptapod 0.16.0 release.