Re: I'm back

[Ben Wagner]

One thing that's been on my mind is around releasing (and this is a
fairly general observation not specific to FreeType). FreeType has
generally tagged a VER-2-X-X release about once every six months and
hasn't had maintained release branches. Distros (and other users)
generally only update to tagged releases or branches and then try to
maintain a patch pile of cherry-picks for bug fixes (essentially a
release branch out of tree). In the present day any non-rolling distro
model is slightly crazy since most open source projects work this way;
the distro should be at more or less tip of tree or there will be
known public exploitable bugs which the distro maintainer probably
doesn't even know should be cherry-picked. However even rolling
distros don't generally always stay at tip of tree to avoid incidental
intermediate API/ABI breakage so tend to lean on the developers to tag
commits to bless them. All of that to say, I think it would be helpful
if FreeType (and more open source projects) tagged bugfix releases
more often. For example if there are no API changes at all since the
previous release tag a bugfix release as soon as reasonable.  It may
seem a bit silly from the developer point of view, but it means that
most users will get bugfixes much quicker. The versioned distros will
still need to cherry-pick things back to their old versions, but users
that keep up to date will benefit greatly.

I was reminded of this sort of issue this morning when I experienced
an extreme version of this issue with the 'ardour' package in debian
which is currently code from two years ago and the package didn't ship
in the bullseye release because the old code didn't work with newer
libraries even though upstream had long since fixed the issue but
there have been no new tags since.

Le ven. 24 avr. 2020 à 16:02, David Turner <address@hidden> a écrit :
>
> Hello freetype-devel@ list members,
>
> It's been a very very long time, but I have some free time in the coming 
> weeks to work on FreeType. Werner invited me to write a small announcement 
> here and I'm currently looking at the official bugs list.
>
> I'd like to know what are, in your opinion, the most pressing issues to work 
> on at that point?
>
> Apart from that, I had the following things in mind:
>
> - Improving / refactoring the build system a little. E.g. it should be 
> possible to simplify the rules.mk/module.mk files considerably, and 
> auto-generate most of the Makefiles / Jamfiles / CMakefiles from a single 
> source of truth (exact format to be defined), at least the parts that deal 
> with the headers / sources / configuration headers and the module 
> dependencies.
>
> - Improve testing (unit and regression tests to be exact) There are lots of 
> possibilities here, and it will probably better to do this in small 
> incremental steps.
>
> Voila, I'd be happy to read your suggestions, Happy to be here.
>
> - David Turner