[fpc-devel] [RFC] Modernising the FPC Release Process -- Proposal for Review

Martin Frb lazarus at mfriebe.de
Fri Apr 17 17:54:16 CEST 2026


On 17/04/2026 17:28, Michael Van Canneyt via fpc-devel wrote:
>
> That is where we have different visions.
>
> If I just wanted git, I would not need gitlab. gitea (or whatever it 
> is called today) does the job.
>
> There were 2 reasons for switching to gitlab SaaS:
> - No maintenance
> - The tooling we get.
>
> If you don't want to use the tooling of gitlab, there is no point in
> discussing, as that is a given for me: setting up some system beside 
> gitlab which does what gitlab does, is IMO utterly pointless if you're 
> already using gitlab.

If it is just the MR click on "cherry pick this" => then I wouldn't call 
that "tooling you get with Gitlab" => for that Gitlab is just a client, 
like any other git client. And you can do that with any other git client.

If it is the ability to add labels (includes milestones), and search MR 
for that => then yes that is tooling. But (and that is not my decision 
for FPC) is it the most efficient tooling?  (regardless of you being 
used to it, and it being easiest to you). But that is between the core 
members of fpc. I can't answer that.

>
> However, if you insist on using a local tool (command-line or not): no 
> problem. gitlab cli (glab) exists already. You can use that to handle 
> merge requests
> without ever touching the web interface.
Can't comment. Haven't looked into it.
But depending on what other members in fpc core team want, that may be a 
selling point.


>
> Gitlab is API first, so If this is your wish, I'll even write a 
> lazarus UI tool or FPC command-line tool to create the MR, merge it, 
> all in one go.
Which would mean you could actually write a tool for all the fpc team 
members that performs all the tasks without needing any knowledgde on 
gitlab....
That should be a selling point. (if that tool is on offer)


Of course, that may bring up another point... Which may or may not have 
been discussed when moving to git (I wasn't part of the FPC discussion 
on it)...
But, I distinctly recall several mention of
"gitlab has the best offer for now, but git allows us at any time to 
roll our own web if gitlab can't be used no longer. Either by our own 
gitlab server with the free parts of gitlab, or any alternative)"
So at that time, it sounded very much that there would be no dependency 
on gitlab.

If I recall that correct, then I guess that is a big decision for the 
future. If the advantage are indeed that good, then it may well be worth 
it.
I don't know the answer to that. But I would caution to explore and 
compare workflows that don't set that kind of dependency....

Mind, that either way, some of gitlabs features are still adding value.
E.g. we run CI for tests. We are not dependent on that. The workflows we 
have will work, even if that discontinues. But for now, having it is great.



>
> If that makes your (and other people's) life easier or more 
> comfortable in a MR-based
> workflow, I am prepared to do the work.
that really is between you and your team mates.

I don't commit to the fpc repo. So I am not affected.

I offer my comments here, as "ideas to be added to the pool".
 From the mail thread it seems that there are different expectations 
around. So maybe in those ideas there is something that can be picked.



More information about the fpc-devel mailing list