New release?

[thesamesam]

Hi folks,

The last release doesn't build with new GCC or linux-headers.

Would it be possible to have a new release of rr?

Also, in the absence of releases, would you be opposed to us in Gentoo possibly shipping a snapshot of rr at a certain commit? (I'm not sold on the latter, I'm just wondering what your perspective is wrt releases and if you view master as unstable or just releases are a pain to do and there's no known issue).

cheers

[jubalh]

On that occasion I also would like to bring up the topic if it would be generally possible to have more frequent releases.
I quite often saw that people open bugs, and I'm even guilty of this myself, that were already fixed on the master branch. In my case I even tried to search for some words before opening a new issue, and still it happened. While there probably always will be a chance that people do that I assume that more frequent releases would help a bit and reduce load on you guys.
At the same time it would reduce load on distribution maintainers since they wouldn't have to backport so many patches. (Which also has to be done for each distribution).
I haven't found a roadmap so I'm not aware how it is currently decided when to release. But maybe this point about more frequency could be considered. Thanks!

[rocallahan]

We should do releases more regularly. It's just a bunch of manual work to verify each release, partly because we want to build and test rr on a variety of distro releases. Basically we do releases when all these conditions are met:
a) it's been a long time since the last release
b) someone nags us
c) I have time
d) there aren't any obviously destabilizing changes that have landed recently
we probably should address a) and b) by trying to release on a regular schedule, e.g. every 6 months. I'm not sure what the ideal timing is to be in the right place for various distros' release schedules.

[rocallahan]

Maybe we should invest in more release automation, e.g. using scripted installs of OS images onto AWS VMs. That's a bunch of front-loaded work though.

[jubalh]

I'm not sure what the ideal timing is to be in the right place for various distros' release schedules.

That will be hard because various distros have different dates. And in many cases those aren't even fixed but are like X months after the last release. And this "last release" can be moving depending on the time between freeze and actual release.

we probably should address a) and b) by trying to release on a regular schedule, e.g. every 6 months.

I think that would be a good idea.

Maybe we should invest in more release automation

I don't know about testing. But regarding building I can offer some help.
The openbuildservice can build packages for various distributions. On our openSUSE instance people can also create private projects (meaning they don't have anything to do with openSUSE. It's more like a project on GitHub). Some projects use this to build packages for various distros.

For example dino puts all the build files in there (PKGBUILD for Arch, spec for Fedora/openSUSE...) and builds packages for: Arch, Debian Testing, Debian Unstable, Fedora 36, Fedora 37, Fedora Rawhide, openSUSE 15.4, openSUSE 15.5, openSUSE Tumblweed, Ubuntu 22.04, Ubuntu 22.10.

There is a service file that pulls the source from git and puts it in a tarball. Then the various build files are read and the packages are build.

So basically this would be a one time effort of setting up the project, collecting the build files from various distros (or ask them to contribute them). And then a repeated efffort upon each release to trigger the service file. Then automatically the packages will be built. So at least we know if rr builds.

However I would just make a release every 6 months and let the distros report bugs if they find any ;)

To automate creating releases we use the following GitHub workflow file in JasPer.

[thesamesam]

Cheers for the quick reply Robert! While I can't speak for Debian (I'm from Gentoo), I can say that generally distros like it when things align, but something predictable > nothing/unpredictable. Things can then get squeezed in as appropriate or tested ahead of time if something just misses a deadline too.

Basically, don't overthink it wrt distro release schedules, because there's so much software released all the time that it can't work that way en-masse anyhow.

But obviously the testing bit is hard if you want to do runtime manual testing to ensure rr works as it should, not just checking if it builds or tests pass.

[rocallahan]

Building packages for different distros isn't really the problem. We release an RPM, a DEB and a .tar.gz and they're all built in a single rr build on the same machine.

What we have to do is:

1. For each distro+version combination we want to test on:
   1. Apply all pending system updates
   2. Pull desired rr revision
   3. Build rr
   4. Run rr test suite
   5. Run extra tests to make sure distro's version of Firefox and Libreoffice can be recorded (see https://github.com/rocallahan/rr-vm-testing)
   6. If any of these fail we need a way to debug the failures easily, i.e. access to the VM
2. Build packages on an old Linux distro (e.g. oldest still-supported Ubuntu LTS) to avoid depending on new glibc version
3. Make a github release with those packages
4. rr-project.org site update

That first item is most of the work. It's automatable but it's a bunch of fiddly work to write the necessary scripts, especially to make them work for people other than me and keep them up to date. Maybe we could use AWS and just ignore any distros/versions that don't have AWS images available.

[rxrbln]

+1 for release early and often. Not really that much testing needed. Just release what works for you and basically any improvement over "current release not building on latest OS with current gcc/clang is an improvement and distros patch what they find broken on their specific systems anyways. Basically OS vendor updates do the field test for you, and if any new bug is found thru this massive parallel community testing just spin a new release. Way faster than not releasing for month or a year. Win-win for everyone! ;-)

[rocallahan]

We've done a new release, and I've built infrastructure to make release testing much easier via AWS VMs.

[jubalh]

We've done a new release

Is it intended that it's not visible on https://github.com/rr-debugger/rr/releases yet?

[rocallahan]

The new release was 5.7.0. That's after this issue was filed. We don't need to do another one yet.