Making new releases of X.Org modules

[Alan Coopersmith]

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.)

-- 
         -Alan Coopersmith-                 alan.coopersmith at oracle.com
          Oracle Solaris Engineering - https://blogs.oracle.com/solaris