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 have started looking at how various distributions / projects configure / build FreeType [1], but only for the latest version (2.10.1).
For that one, the list of patches is rather minimal imho (most are about changing configuration options).
We should probably look at the patches applied on top of previous releases as well and see what important things should be moved into a release branch.
I'll file a bug for this with more details. The main question will be how long do we support older releases, and what goes into fixes (I would suggest only security fixes as a starting point).
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.
[1] Nix:
https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/libraries/freetype (subpixel-rendering + table-validation)
Debian testing:
https://packages.debian.org/testing/libs/libfreetype6 (subpixel-rendering + table-validation + scale-phantom-points + verbose-libtool)
Ubuntu focal:
https://packages.ubuntu.com/focal/libs/libfreetype6 (same as debian)
Fedora:
https://src.fedoraproject.org/rpms/freetype/tree/ (subpixel-rendering + table validation + ABI fixes(?!?) + libtool fixes)
OpenSuse:
https://build.opensuse.org/package/show/openSUSE%3AFactory/freetype2 (subpixel-rendering, enable long family names, enable infinality, libpng-not-required, cmex-font-workaround)
ArchLinux:
https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/freetype2 (table validation, enable infinality, enable long pcf family names, phantom points)
Gentoo:
https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/freetype/freetype-2.10.1.ebuild (TODO)
FreeBSD:
https://www.freshports.org/print/freetype2/NetBSD:
https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/graphics/freetype2/patches/ (TODO)
OpenBSD: only using freetype 1.3.1 !!
ReactOS: ??
Skia:
https://github.com/google/skia/tree/master/third_party/freetype2modules: no raster1, type1, pfr, bitmapped formats
options: seems to be using the default, i.e. no subpixel rendering, no harfbuzz, no adobe glyph list
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