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

[Marco van de Voort]

Op 17-4-2026 om 17:48 schreef Michael Van Canneyt via fpc-devel:
>
> Maybe use another tool than tortoisegit ?
> I used it in the past. It's an ill-conceived fork of tortoisesvn.

It is much worse than T-SVN was. But it works in a pretty vanilla 
install, and does not require a bunch of scripting for basic operations. 
That lessens keeping heaps of scripts synchronised between machines. 
Keep in mind that I mostly work on single commits on multiple machines. 
Having everything stashed in some local branch is not workable for me.

Also: I have to write off all time I spend on git and gitlab on my time 
spent on FPC.

> I don't much care for UI tools but what I see from my colleagues who 
> do use
> UI tools, none of them has to do so many clicks as you describe.

Then retest. Make sure you have a few files dirty, even if only a few 
.lpi's for e.g. the compiler or so (because you added a few run 
parameters). I can make a video?

>>> Unfortunately, the FPC project seems to have stalled since the 
>>> migration, and there is no clear consensus on how to properly 
>>> leverage these new [2026] tools. Given that, I don't believe there 
>>> is much more I can contribute at this stage. I’ll stay on the 
>>> sidelines for now and hope for the best. And yes, I'm still happy to 
>>> triage/review Merge Requests where I can. Could we at least get some 
>>> triage labels added to the fpcsource project, as I suggested in the 
>>> proposal?
>>>
>> Always the my way or the highway attitude, all along the way implying 
>> the opponents are Neanderthals for their efforts to engage with you.
>
> Looking at it from aside, the 'engage' very much resembles breaking 
> down every proposal that comes along.

That is a matter of viewpoint. The other side would argue that those 
proposals are basically all the same, just reinserting the same coin 
over and over again each time an issue/discussion comes up in the 
project, adopting more gitlab workflow will solve everything, even if 
that was not the question. Specially since people involved with releases 
mentioned umpteen times that the current delays are not due to tooling.

>
> You may not intend it like that, obviously, but
> this is not very motivating for users who wish to help.
>
> Graeme offered help, he still offers help - triaging.

He offered help, but with conditions. Moreover it doesn't help to 
constantly label people opposed to whatever you do as behind the curve, 
without even inquiring circumstances.

Maybe I'm hyper sensitive to that due to the history of git before, so I 
apologise for any harshness.

But the point is that we were talking about releasing , not resetting 
the tooling and redesigning the workflow of the whole project.

I attempted to bring some real world knowledge and did a outstanding 
revisions to merge count and showed that MRs are a tiny part of that 
number, even if I overestimate it several times.

And what do I get as answer?  "Centralise MRs in every aspect of the 
development process" then.

What other reaction would you guys expect on statements like that?

Those changes are btw not beyond discussion, but only if they are 
somewhat proven with little experiments.  And specially not over the 
backs of an already enormously delayed release process.

And getting back to releasing, work has to be done now. Not tooling for 
future use which will be visible after 2030 with the current pace. And 
with more upheaval we might not even make that deadline.

The fixes release should be routine, and not even worth discussing. 
(just do it), but _NOBODY_ is discussing in this thread about the 
viability of branching main somewhat soonish. That should be the number 
one topic, not whatever workflow gitlab has just enabled.

> I can imagine your last reply is very off-putting for him.

I can imagine, and I apologise. I was red hot because of the above 
reasons. But at the same time I hope he gets that workflow is sensitive, 
and that there is far from a consensus about that.

But anyway, put your MR to the test on the main list, and we can maybe 
get passed this in one swift swoop, for good or bad. I'm not a top 10 
committer, and easily overruled.

>
> You could get reactions like this:
>
> https://components4developers.blog/2025/06/10/i-left/
>
The question is, if you can avoid such reactions at all. This is a 
typical reaction of somebody who doesn't get his way.  A nice dramatic 
epitaph like statement without much dialogue to counter it.

What other solution is there to avoid this, just  acquiescence to every 
random request, no matter the strings attached?