> On Dec 8, 2022, at 16:22, Peter Hutterer wrote:
>
> 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 :)
While we're on the topic of fonts, I think it would actually be great to merge
all the fonts into a single package like we did for all the protos. If we
could eliminate the configure time for ~35 packages, it would certainly help
build times.
>
>>> 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.
>
