New way of releasing gedit

Applications
,
1

New tarballs of gedit and related projects are no longer uploaded to download.gnome.org, instead git tags are just created (with git evtag).

So the gedit projects don’t use the new GNOME CI machinery for tarballs.

GitLab provides automatically generated archives (e.g. a *.tar.gz), but unfortunately it doesn’t include git submodules. The gedit repo has one submodule (for the libgd), so another method of packaging is needed for gedit.

2

So the gedit projects don’t use the new GNOME CI machinery for tarballs.

If you wanted, there isn’t anything that would prevent gedit from using the new way to keep uploading dist tarballs in the ftp.

Shouldn’t matter much hopefully since most infrastructures nowdays can build fine from plain git tags.

1 Like
3

I don’t want to discuss it in length, but in short:

  • Lack of time to learn and setup GitLab CI.
  • GitLab CI can break in various ways without being our fault (e.g. when the infra is unreliable).
  • The need to dig into lengthy log files in case of problems.
  • It’s more resource hungry (for servers, but it’s just someone else’s computer).
  • In GNOME upstream, build instructions come in many flavors: BuildStream, Flatpak manifest, JHBuild, lots of different ways to do GitLab CI (based on different base images). Thankfully GnomeContinuous is behind us. I’m maybe forgetting others. So at least 4 different ways. Lots of duplication work done by the various CI jobs (with Meson, calling ninja test; ninja test executes two times the entire test suite. I know a little Bazel, another build system that is smarter and re-builds or executes only what has changed). The overarching picture is a bit saddening.

So, I don’t have a keen interest in CI solutions, sorry.