>> If you want to submit general changes to FreeType please submit >> MRs. However, for your ftinspect GSoC stuff you should push to a >> personal branch (or even branches, if necessary) of the upstream >> repositories *without* MRs. In your personal branch(es) you can go >> wild – no need for forking:-) > > Well... As is mentioned in the proposal, my original idea was to > have the code merged from my dev branch to master immediately after > one functional is completed (more like the workflow I experienced in > some other projects) ... So it would be a lot of branches and MRs > (now those temporary branches can be directly pushed to the upstream > repo). I'm actively rebasing and re-organizing my commits so > they're ready to be merged into master. > > The main reasons are: 1) MR provides a good tool for code reviewing > and progress tracking. With GitLab Issues, it would be a lot more > convenient to discuss project details. 2) Continuous merging > ensures a better overall code quality because this would require the > quality to be always ready to be merged. > > However, I'm OK with the personal branch , if you insist :) .
Here's the thing: At the end of GSoC, you have to write a report that references your code. This means that people not directly involved with FreeType should be able to understand your contributions. While FreeType is a rather slowly moving project, it still moves. If everything of your code is in a single, final branch, you have a single reference. Otherwise, you get a bunch of references to the git repository, probably interspersed with other commits that change code related to `ftinspect`, too. My conclusion: If it weren't for GSoC, your approach would be just fine. However, for the sake of having your code at one single place I ask you to use one or more working branches, with a cleaned-up reference branch holding logically organized commits as the final GSoC target. BTW, it might help setting up CI support for 'freetype-demos', and in particular for `ftinspect`. Can you do that? Werner