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

[Werner LEMBERG]

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