Making new releases of X.Org modules

[Peter Hutterer]

On Wed, Dec 07, 2022 at 05:37:27PM -0800, Alan Coopersmith wrote:
> Normally when I go through the list of modules which have had git commits
> since their last release was tagged to decide what to make new releases of,
> I skip over those which only have changes that don't really affect the
> installed files, such as the changes for migrating to gitlab, autogen
> script updates, CI updates, changing the tarball type from .bz2 to .xz, etc.
> 
> This has resulted in some modules not getting released in many years.
> For instance most of the font modules were last released in 2010, but
> have an assortment of small changes we could release, like:
> https://gitlab.freedesktop.org/xorg/font/adobe-100dpi/-/commits/master
> but which wouldn't result in any changes I see to the installed font files.
> 
> But we keep getting bugs filed for the ancient generated autoconf scripts
> not recognizing new platforms like RISC-V, such as the 4 "BUILD FAIL" bugs
> on https://gitlab.freedesktop.org/groups/xorg/font/-/issues .
> 
> And I've had another distro packager email me recently asking to make
> new releases of various drivers, such as all the xf86-video-sun* modules.
> 
> Am I being too picky about deciding if a release is warranted?  Is it
> going to annoy other distro packagers if we make a few more releases
> than we have before?  (Maybe ship font package updates every 6 years
> instead of waiting for 12?)
> 
> Honestly, from a purely selfish point of view with my day job hat on,
> having a few more releases helps us since our policy requires reviewing
> any FOSS package that hasn't had an upstream release in the past few years
> to verify it's not dead/abandoned/etc. and it's less work for me to
> make a quick package release than it is to go through our review process.
> (Which is admittedly why there have been a number of recent releases that
>  just fix compiler & cppcheck warnings when there's nothing else to do.)

fwiw, I've done similar things in the past, pushing a release out just
to make some internal processes easier. It's simpler to update to a new
version than shipping the one patch that's actually needed (and all
other patches are just readme changes and whatnot).

But for me, the threshold is the tarball, not the installed files.
The only time I wouldn't create a release is when the tarball is
effectively identical. Which is basically anything that's CI-only.
But anything that affects the delivered tarball can be subjected to a
release.

This goes doubly now that many repos have changed to xz so we have a mix
of tarball types too. Releasing everything in one group to get some
consistency is useful.

And as the font bugs show, sometimes a release is warranted just to
update the tarball with more modern generated files.

IOW, let's not worry about whether releases happen too often, it's a lot
easier for distributions to ignore a released tarball than it is to wish
a newer one into existence :) Especially since "too often" here still
means years in between the releases anyway.

Cheers,
  Peter