Re: [GSoC] Merge Request - to master or to a seperate branch?

[Werner LEMBERG]

> 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.

This should work.  However, I'm not sure whether this works out as
intended: I tend to walk over a branch again and again (using `git
rebase -i`) until all commits are in a good shape.  Cherry-picking
prevents that approach; modifying commits at that stage would be very
confusing.

> 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.

Why do you think that?  Simply do `git rebase master` from time to
time to fix this.

> Also, the code quality may lose control and end up like the
> previous GSoC project about ftinspect :( .

Believe me, the problems with the previous `ftinspect` project were
definitely *not* git issues :-)

>> 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?

Ideally the same platforms as used in FreeType's `.gitlab-ci.yml`.


    Werner