Making new releases of X.Org modules
Matthieu Herrb
matthieu at herrb.eu
Fri Dec 9 07:11:21 UTC 2022
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.)
>
Thanks for all this work.
As the OpenBSD packages (xenocara) maintainer, I appreciate having
releases of latest code. Exeperience has shown that apart from the CI
tests there are very few people running the head of the main branch of
the git repos, so there is not much real life testing of new code
before it gets released.
So currently having releases that get pushed to OpenBSD-current, Arch
Linux and other rolling releases helps with testing patches. (the
libX11 pthreads stuff is a good illustration ihmo).
--
Matthieu Herrb
More information about the xorg-devel
mailing list