Making new releases of X.Org modules

[Peter Hutterer]

On Thu, Dec 08, 2022 at 12:34:33PM -0800, Alan Coopersmith wrote:
> On 12/7/22 19:07, Peter Hutterer wrote:
> > 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.
> 
> Fair enough.
> 
> > 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.
> 
> That almost sounds katamari-like. Fortunately, we're getting most things
> released without the overhead of a katamari release anyway.

biggest difference between now and the katamaris is that while 
consistency is useful, if it takes a few months to get every package to
catch up it's not a big deal, no need for the flag-day stress of the
katamari.

Also for clarification, I meant "releasing everything that belongs to
one group", e.g. releasing all the font modules so they are consistent
with each other. I didn't mean release everything *as* one group, too
much effort, that :)

> > And as the font bugs show, sometimes a release is warranted just to
> > update the tarball with more modern generated files.
> 
> Yeah - I know they can just run autogen.sh or autoreconf to get their
> builds to work, but I know it's less work to just have upstream usable
> right out of the tarball.  (And of course, once everything builds with
> meson and the autoconf infrastructure is removed, that goes away, but
> we don't have enough people converting modules to meson to see that yet.)

Given that there's still too much documentation that refers to only
running configure on tarballs, I agree, they should be usable as-is
without autoreconf.

Cheers,
  Peter

> > 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.
> 
> Okay - I guess I just see things like
> https://repology.org/project/fonts:adobe-100dpi/versions
> or
> https://repology.org/project/libx11/versions
> and think about how many different packagers I'm making do work, but
> if that work is just changing the version number of the tarball they
> download, they should have that pretty well automated by now.