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 <[email protected]> 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
