My conclusion: If it weren't for GSoC, your approach would be justfine. However, for the sake of having your code at one single place Iask you to use one or more working branches, with a cleaned-upreference branch holding logically organized commits as the final GSoCtarget.
I see. If I set up a parallel personal branch (gsoc-2022-chariri) cherry-picking my contributions, while new commits are still being merged, would it work? The parallel branch would serve the purpose of proof-of-contribution and it will be a logically organized single line.
The main concern is that, if the dev branch isn’t actively merged, it may end up being a huge merge-conflict hell at the end of the GSoC. Also, the code quality may lose control and end up like the previous GSoC project about ftinspect :( .
BTW, it might help setting up CI support for 'freetype-demos', and inparticular for `ftinspect`. Can you do that?
If it’s only for |ftinspect|, it’s fine since it requires few dependencies. Which platforms are needed?
Cheers, Charlie
