What’s in a SingularityCE Release?

May 23, 2022 | Blog, SingularityCE Updates

Now that SingularityCE 3.10 has shipped, let’s take a look at what’s in a release, and who makes it happen. Our goal is that SingularityCE should be a true community project that is accessible to both users and developers. At each sixth-month release, going forward, we’d like to take a look back to thank all of the contributors, and assess whether we are making progress toward that goal.

A SingularityCE release consists of code from a number of first-party GitHub repositories, and a lot of dependencies. We’ll concentrate on just the first-party repositories. These are the code that’s specifically written to be part of Singularity:

All of this code is open-source, released under the BSD license, and contributions are very welcome. Note that we’re including the documentation here, as that’s at least as important as source code, and it’s a great place to dive in first if you’d like to get involved!

Long time contributor to Singularity, and prolific developer, vsoch has written a great tool called citelang that we can use to help explore contributions.

We’ve used ‘citelang contrib’ to count the number of lines in contributions between the SingularityCE 3.9.0 and 3.10.0 releases. We’re excluding `go.mod` and `go.sum` files (which have a lot of automated changes, thanks dependabot!). The total contributions across the repositories above are then added up. Work on SIF or the user documentation is just as important as work in the Singularity runtime itself.

Contributor
Lines Added/Modified
David Trudgian
13911
Adam Hughes
4230
Mike Frisch
1574
vsoch
359
Dave Dykstra
177
Tom Schoonjans
47
Vadym Lesich
47
Roman Briskine
7
Adrian Wobito
5
Richard Hattersley
3
Andreas Plesch
2
Nathan Weeks
2

So there we go… 20,364 lines were added or modified by 12 contributors in this release cycle. Thanks to everyone who pitched in!

The distribution is heavily weighted toward Sylabs employees, which we’ll always expect to be true as we are committed to the general maintenance and bugfix work needed to sustain the open-source project. However, it’d be great if SingularityCE did attract more community developers. We believe It’s important to have lively engagement to ensure the project really does reflect the needs of users.

We’d also like to give a hat tip to Apptainer, especially DrDaveD, who is the driving force behind development there. As you can see, we’ve brought in some of his code from Apptainer, and the open-source license of SingularityCE ensures they can benefit from the work over here, too. Since their 1.0.0 release Apptainer has merged in 40 pull requests from SingularityCE, which will form a good part of the feature-set of their upcoming version 1.1. The Apptainer project is also able to pull in the majority of the SIF, documentation, and scs-client work to their forks of those repositories.

Generally SingularityCE pulls a lower percentage of Apptainer code, than Apptainer pulls from CE. The reason for this is our roadmap, which is taking a different approach to the issue of improving OCI compatibility. As we have discussed previously we are working toward full compatibility, without sharp edges, by using a true OCI runtime engine and supporting the encapsulation of OCI images in the SIF format. This means that a different approach is sometimes required for some features.

Over the next six months toward SingularityCE 3.11 we’ll be trying to encourage more community contributions, and reaching out for feedback and input on upcoming features. Please let us know if you think there’s something we can do better. We’ll take another look in six months time to measure how it’s going.

Join Our Mailing List

Related Posts

QA and Stability in Singularity

There are many different approaches that can be taken when building software. At one end of the spectrum is the extreme caution and conservatism that’s appropriate, for example, of safety critical code used in vehicles or in real-time operating systems. At the other...

read more

Improve Security in your CI/CD Workflows

In the development world, continuous integration is where members of a team integrate all their work frequently, for example, think of a team all working on the same code base, they are fixing bugs, implementing new features, so to prevent conflicts, all the code is...

read more

Pin It on Pinterest