Hi,

I don't know the FPC development process, so was wondering if 134 open merge requests are considered "normal" for this project? Some MRs are as old as 5 years. 😬

https://gitlab.com/freepascal.org/fpc/source/-/merge_requests

Regards,
- Graeme -

I consider it by no means "normal".

But verifying takes time and we're dramatically short on manpower.

What I can judge, I try to resolve as quickly as possible. Compiler-related merges in general fall outside my competence zone, so I seldom touch them (apart from adding the category label).

Michael.

I run into the same problems since most of my merge requests are focused on optimisation of generated assembly language, which does require a very careful eye to verify, and even then edge cases can sometimes still get through.

Recently I've been working on compiler features, namely pure functions and vectorisation.  The vectorisation one has a potential code flow problem but I think was necessary due to how SIMD registers work on x86, but as a result is currently sitting in limbo.  And pure functions have been sitting around for 2 years, and developed over 2 years before that!  I would like it merged into the trunk so I can start development of the next stage - the ability to assign the results of pure functions to constants - but it itself is waiting on a merge request that overhauls the Currency type to be more internally consistent in the compiler so constant propagation works properly on it.

As much as I want to say "Just trust me, bro" and have them merged, that tends not to fly in software development circles!! Granted, I do wonder if, with some things, it's worth merging them and then fixing the teething problems as they arise.

Kit

That's exactly what I mean by 'can I judge them'.

Given that it is a one-click action to revert a merge, it is of course tempting to lower the treshold...

Michael.

If that's the case Michael, might it be worth merging the Currency overhaul that pure functions depend on?  It may require some testing on other platforms beforehand, especially i386 since it uses the floating-point stack (whereas almost all other platforms use general purpose registers instead), but the testing I've done so far tells me that it's holding.

Let me know what thresholds I need to reach prior to a merge, besides remembering to tag them properly!

Kit

Michael Van Canneyt wrote

I consider it by no means "normal". But verifying takes time and we're dramatically short on manpower.

That does seem like an awful lot of changes (improvements and fixes) just sitting there in limbo.

If it's burnout, I fully understand that too. I went through that, along with a career change, and took a six-year break from the fpGUI project. Recently I returned, and I felt so motivated to complete my outstanding to-do list. I managed to do more in these last six months than I did in the previous six years!

I must say, I was also very surprised after I returned to see no FPC releases in five years—not even a fixes release!

When you say "short on manpower," are you referring to those developers who have commit access but aren't doing code reviews? Or are you suggesting that the community is not helping?

If the latter, how can I (we) help? I'm more than happy to help with reviewing, but I don't want to do that if FPC developers will simply ignore such 1st-pass reviews regardless.

On a side note:
---------------
One thing I've realised with fpGUI and PasBuild is that I used to go 1–2 years between releases (in the case of fpGUI) because I wanted everything perfect. But I suffered from feature creep—"just this one more feature," then that, then another. The reality is that hardly anyone tests "in-development" branches, so the feedback cycle was near zero. I always had to create "maint" releases too, which was even more work for me.

I've since switched to time-based releases. Think of it as a "train schedule" release cycle. Freeze a release branch one or two months before the release is due. Whatever features didn't make it in before the freeze will just have to wait for the next train—say, in six months when the next release happens.

This also means more people will use the releases, leading to wider testing and better feedback. (Lean on the community!) If feedback isn't great, improvements will come in the next six-month cycle. If a critical issue pops up—which should be rare, assuming the test suite caught the big ones—then make a hot-fix release just to patch that specific issue.

We are all developers here, so releases don't even need installers or anything fancy. Simply a source archive or a Git release tag with a README explaining how to build it yourself.

Regards,
- Graeme -

Problems:
- time to review properly
- they are often not fully tested for all border cases (architectures, platforms etc.), if I merge them, I am responsible to fix broken things
- some are dubious regarding code style/approach
- some are language extensions where there is no consent if it’s useful

If it's burnout, I fully understand that too. I went through that, along with a career change, and took a six-year break from the fpGUI project. Recently I returned, and I felt so motivated to complete my outstanding to-do list. I managed to do more in these last six months than I did in the previous six years! I must say, I was also very surprised after I returned to see no FPC releases in five years—not even a fixes release!

Multiple reasons:
- it’s a boring job
- fpc releases require an awful amount of handwork like updating version numbers in multiple files like readmes, whatsnew, utils etc.
- tracking progress is documented in the wiki, another pain
- FPC repository structure directly converted to git make working with it a nightmare: git sub modules reference to a certain revision, so when something is updated in a release branch of fpcsrc, the „super“ module (i.e. fpcbuild) needs an update as well, makes working very messy. In principle sounds doable, in practice one messes up permanently, in particular when working on multiple machines and with multiple repositories.
- lack of time

Amen to that.

3 suggestions to reduce the pain:

- script/code the version change stuff (But I know you're working on that already)

- Repo structure: probably it is better to use git subtree. It's meanwhile well established. It corresponds more to what we need, I think.

- Track progress:
I think having an milestone/epic and a task list in gitlab could be helpful. In that case multiple people can work on it and it would be fully tracked. We could even accept merge requests for it.

If I can help with some of these things, please let me know.

Michael.

Op 3-4-2026 om 20:21 schreef Florian Klämpfl via fpc-devel:

IMHO it lacks the major one.:

- actually making sure the branch contains all must have fixes and revisions it should have.

P.s. can we open the fixes branch for merging again? A 1 1/2 year freeze makes it a bit stale.

am i right in saying that "134 open merge requests" means that if those 134 requests were applied to the last official FPC release (3.2.2) this would bring it fully up to date with the most recent sources on GitLab?

if this is so, and on the basis that 3.2.2 has been working reasonably well for almost everyone who uses FPC to generate binary applications (as opposed to those who merely enjoy tinkering with the internals of a compiler), might i suggest the following strategy:

pick a handful of merges that (a) provide USEFUL improvements, and (b) are non-contentious. eg, stop the CPU catching fire on long compiles, perhaps add a feature that everyone desperately desires. by a handful, i mean 5 or 6. and the list need not be 'perfect', this is not something as important as creating the perfect mix tape to catch the heart of the love of your life!

now apply the above list (of 5 or 6 merges), and generate a release candidate - a COMPLETE release, like the releases on SourceForge. none of this 'clone the repository and compile it yourself' faff. put it out there, on SourceForge, and sit back and wait.

if there are no complaints in the next 4 weeks, repeat with another handful of merges. it seems to me that given the past lack of progress in the last 4+ years, this is the ONLY way to move forward.

cheers,
rob :-)

Who defines a)? Do you have a list?
Who guarantees b) for all platforms?

now apply the above list (of 5 or 6 merges), and generate a release candidate - a COMPLETE release, like the releases on SourceForge. none of this 'clone the repository and compile it yourself' faff. put it out there, on SourceForge, and sit back and wait.

Who does generate the release candidate?

Agreed - one of the fixes I made to the register allocator was for a dangling pointer bug that exists as far back as the git history - that's one thing that definitely needs to be merged into the fixes branch: https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1074

Merging to the fixes branch should be under greater scrutiny than the trunk though since we have to make sure it doesn't make things worse.

Kit

So another rc :)?

Ah yes, probably.  I might have misunderstood the purpose of the fixes branch, or if the RC has been released yet.

Kit

Sent: Sunday, April 05, 2026 at 12:16 AM From: "Florian Klämpfl via fpc-devel" Who defines a)? Do you have a list? Who guarantees b) for all platforms?

it does not matter who defines the list - if you are completely paralyzed by indecision, pick numbers from a hat. and there are no guarantees, this is a roll of the dice to try and push forward, if it all goes to custard you've just wasted a month of time, while pales in comparison to the elapsed time since the release of 3.2.2.

Who does generate the release candidate?

a competent person? or is part of the problem that there is no competent person(s) in the team who are capable of generating a release candidate?! in that case, lets just all give up and go home now; 3.2.2 is as good as it is ever going to get.

from an article i was reading recently:

" ... [a notable researcher] writes about effort miscalibration, which comes from the psychological concept of “affective forecasting error”. This is our human instinct to over estimate how hard something is going to be. We’re basically not very good at predicting our future emotional state, and so we often avoid taking action because we assume that it’s going to take a lot of effort.

That’s why you often put off [administrative tasks], because you assume that’s going to require way more energy than watching another episode of the TV show you’ve been binging lately. Except that if you think about the times you pushed through that initial effort hurdle, you probably actually had a great time [creating a release candidate] and afterwards thought “we should do that more often”. "
it seems that the whole FPC project/team is suffering from the above. see also: https://en.wikipedia.org/wiki/Affective_forecasting

cheers,
rob :-)

robert rozee via fpc-devel schrieb am Sa.,
4. Apr. 2026, 13:13:

am i right in saying that "134 open merge requests" means that if those 134 requests were applied to the last official FPC release (3.2.2) this would bring it fully up to date with the most recent sources on GitLab?

No. These merge requests are against main and either fix bugs or add features there. They have nothing to do with 3.2.x.

We already have a 3.2.3 that's in rather good shape, but needs a few final merges (e.g. some fixes for macOS) and then the final push to get it out the door as 3.2.4.

Regards,
Sven

Op 4-4-2026 om 13:40 schreef Florian Klämpfl via fpc-devel:

> Agreed - one of the fixes I made to the register allocator was for a dangling pointer bug that exists as far back as the git history - that's one thing that definitely needs to be merged into the fixes branch: https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1074 > > Merging to the fixes branch should be under greater scrutiny than the trunk though since we have to make sure it doesn't make things worse. So another rc :)?

Was RC1 ever offcially published?

But yes, considering the 1.5 year time frame, a new merge round and RC seems prudent.

The infrastructure for automating has improved immensely with the move to a git workflow and gitlab hosting. But it needs more work to be a fully automated CI/CD pipeline. Any manual work still being done should be evaluated, simplified, automated or eliminated. A properly implemented CI/CD should be able to automatically generate a full release.

If you use LLMs try this query:
"The Free Pascal project (FPC at https://gitlab.com/freepascal.org and https://www.freepascal.org/) is having problems preparing and creating new release versions due to all the manual work involved. What practical steps are needed to fully automate the CI / CD and with the goal of completely automated release builds?"
and
How do these techniques apply to the goal of automating builds and releases?: "defined as code", "cloud native", GitOps, ContainerOps

We already have a 3.2.3 that's in rather good shape, but needs a few final merges (e.g. some fixes for macOS) and then the final push to get it out the door as 3.2.4. From the top of my head there ar at least 2 fixes for file handling on

Windows (so they will not affect other systems), and for one of them merging to fixes was denied with something like "not if I can help it".
Which was rathter discouraging.

Op 4-4-2026 om 13:08 schreef robert rozee via fpc-devel:

am i right in saying that "134 open merge requests" means that if those 134 requests were applied to the last official FPC release (3.2.2) this would bring it fully up to date with the most recent sources on GitLab?

No, that would be around 13692 revisions, the number of commits between 3.3.1 and 3.2.x.

See http://www.stack.nl/~marcov/mergelogs32/ for a break down.

Of course those would never be all merged to a stable branch, but that is the pool to get merge candidates from.

Hi Florian,

Florian Klämpfl wrote

- they are often not fully tested for all border cases (architectures, platforms etc.), if I merge them, I am responsible to fix broken things

If a merge breaks something, you can simply revert the MR and notify the author. GitLab makes this very easy. Since the "main" branch is intended for development, most people don't expect every MR to be perfect immediately. If you do expect perfection, I'm afraid you are in the minority. Once merged, code receives significantly more testing—even if only from the few who use the "main" branch daily.

The "git" repo itself uses a special branch where MRs are reviewed and merged for testing before moving into the release-candidate branch. Since FPC doesn't have the same volume of traffic or developers, using the "main" branch for this purpose makes the most sense.

- some are dubious regarding code style/approach

If "code style" refers to formatting, FPC already includes its own formatter — it’s just that the configuration is incredibly confusing. I tried using it for my recent OPDF code, but the output looked nothing like the rest of the compiler source, so I reverted the changes. You could implement a pre-commit or pre-merge hook in Git to run a formatter automatically, but it requires a clear set of rules.

Speaking of which: I recently asked about FPC's code formatting rules so I could adapt my MR. It seems there isn't any accurate documentation. The wiki page suggested was quickly debunked as outdated or incomplete. Currently, the "formatting rule" is essentially just: "Look at the surrounding code and try your best." :shrug:

Multiple reasons: - it’s a boring job

Automation is the answer here.

- fpc releases require an awful amount of handwork like updating version numbers in multiple files like readmes, whatsnew, utils etc.

This is extremely simple to automate. You can even use AI to help script it. You don't have to spend money; just use Gemini’s CLI with a free Google account. It can handle these updates in a fraction of the time a human would. At my workplace, we’ve automated almost every laborious task using AI — it's incredibly effective at it and allows developers to focus on the fun part: writing code.

- tracking progress is documented in the wiki, another pain

For fpGUI and PasBuild, I let AI do the work. I used to maintain a changelog.txt manually, but now I just have AI scan the Git repo between two tags. It does a brilliant job, even generating migration instructions for breaking changes. Use AI as another tool in your developer toolbox; it's a massive time saver.

- FPC repository structure directly converted to git make working with it a nightmare: git sub modules reference to a certain revision,

I agree — Git submodules have been a pain since they were invented. There are much better alternative solutions available today.

Regards,
- Graeme -

As I see it, there are two ways to simplify matters significantly:

1. Move to time-based releases, as I explained in my initial message. These
would be based on the "main" branch.

2. Anything merged into the "main" branch that qualifies as a hotfix can be
marked in the MR with a milestone version (the next fixes release number).
That way, GitLab tracks all outstanding milestone items for you, making it
very easy for multiple people to work through the list.

The more radical approach:
--------------------------
However, given the limited manpower and time the FPC team is currently experiencing, I would suggest an even more radical approach: **ditch "fixes" branches completely**, unless a truly critical bug slips through. In those cases, fix just that specific issue, add a test to verify it, and ship that point release as a hotfix.

It would be better to spend the limited time available on improving the efficiency of the release cycle instead. If a time-based release every six months becomes a "no-brainer," it results in less effort for the FPC team and more frequent releases for end-users—leading to more widespread usage and better feedback.

Regards,
- Graeme -

It also leads to a more buggy compiler though. FPC has great stability and i think not making a release until the compiler is stable enough is a good thing for end users. People who can and want to test the compiler to find any bugs can already use the main branch - which is decently stable too. Personally i'm using the main branch that i update occasionally as my "main" (:-P) version and only use 3.2.2 when i want to make sure the code compiles with it.

TBH i never saw the point of time-based releases, yes you get faster and more often releases but those releases are not necessarily of a good quality.

FWIW i agree that the release cycle may need tweaks, but i think it should be based on what bugs/tasks are to be fixed/done for a release and come whenever those are fixed/done, not in fixed timesteps - especially since FPC relies largely on volunteer work who work in their free time. It isn't like the FPC devs have a bunch of MBA's with quarterly growth goals to please :-P.

Kostas

Kostas Michalopoulos via fpc-devel kirjoitti 6.4.2026 klo 15.42:

"/release cycle may need tweaks/"... For God's sake Kostas, why you repeat that mambo-jambo? Those same things have been repeated year after year after year.

None of the FPC development team seems to have any intention to make a release. The release manager here asks "Who will build the release". He has no idea. The whole team has clearly dropped the ball. They have time to write posts and messages to explain why a release is not possible. They could have released many versions already with that energy.

Help has been offered, first in forum threads, now here by Graeme. FPC developers are not interested apparently.

Lazarus project and many FPC users are in dire need for a release and then more releases in reasonable time intervals. I see forking the FPC project as a more and more compelling option. The fork would concentrate on timely releases. Lazarus would officially support the fork, then it could become popular. It would need a dedicated team. The first task could indeed be to automate the release build process.

My prediction is that after one year from now there still is no new release, based on the attitude of FPC developers. Would people then agree with the forking idea? Start to think of names for the fork.

Regards, Juha

Would be great if someone else does the releases, waiting for years someone finally shows up to do so :)

While I agree it would be nice to see a new release soon, releasing a new version for the sake of releasing a new version I wouldn't recommend if it contains features that are half complete.  No need to be rude about things.

Believe me, as an FPC developer I am trying to fix bugs and get some new features introduced into the compiler, like pure functions.  While I have merge rights, I'm wary about merging big additions lest there are bugs that I've overlooked (hence the need for code reviews, although sometimes I can't change what they request and have to try to justify it).  Also my focus is on code generation and peephole optimisation, so anything involving packages and other components I tend to not review unless it's something fairly simple (I've also only started to review other people's code at my own volition).

You're welcome to create your own fork of Free Pascal, as per the GNU General Public Licence - believe me, I was tempted to at one point as well because of my focus on low-level optimisation conflicting with the cross-platform nature of the compiler somewhat.  I've worked around that since with better code generation.

Kit

J. Gareth Moreton via fpc-devel kirjoitti 6.4.2026 klo 22.23:

... I am trying to fix bugs and get some new features introduced into the compiler, like pure functions.

Those are in FPC trunk which is very far from release. Now the release we are waiting for is FPC 3.2.4, a bug fix dot release. I have understood it only requires merging some known revisions and then can be released. It even had RC1 version at one point but then was forgotten.

Regards, Juha

Kostas Michalopoulos wrote

It also leads to a more buggy compiler though. FPC has great stability and i think not making a release until the compiler is stable enough is a good thing for end users.

Respectfully, I disagree that time-based releases inherently lead to more bugs. In fact, the current 5-year gap since the 3.2.2 release is causing a different kind of "instability" for framework developers and end-users.

When the "main" branch hoards fixes, features, and updated OS APIs (Windows unit, BaseUnix, fcl-passrc, macOS improvements) for half a decade, it puts external developers in an impossible position. We cannot reasonably ask our users to switch to an in-development branch for production work, yet staying on a 5-year-old "stable" release means we are forced to maintain a mountain of internal workarounds for bugs that have long since been fixed in FPC's repository.

The Benefits of Time-Based Releases (as seen in OpenJDK, LLVM, etc.):

* Predictability: Framework authors can plan their roadmaps knowing exactly when they can deprecate old workarounds.

* Reduced "Fixes" Overhead: With a 6-month cycle, the need for complex backporting to "fixes" branches diminishes. If a feature misses a window, it's only 6 months away, not 5+ years.

* Better Feedback Loop: More frequent releases mean more users testing the "new" code in real-world scenarios sooner, rather than a massive "big bang" release that is guaranteed to have regressions due to the sheer volume of 5 years of accumulated changes.

* Automation over Manual Labour: The "man-power" argument is real, but the solution is to automate the release engineering process (CI/CD, test-suite validation) so that a release becomes a "non-event" rather than a heroic manual effort.

Kostas, you mentioned you use the main branch daily and have commit access. That is a luxury many of our users don't have. For those of us trying to build an ecosystem on top of FPC, the lack of a formal release makes the compiler feel stagnant to the outside world, even if the repository is active.

I am more than happy to contribute missing APIs for the Windows unit or fix broken constants I discovered in BaseUnix, but having to wait 5+ years before other developers can benefit from those contributions is simply not right. It doesn't take a genius to recognize that five years is an eternity in software development.

We don't need every release to be a "major" milestone. We just need the "stable" baseline to move forward at a pace that matches the modern development landscape. If we don't address this, we risk fragmenting the community further.

Regards,
Graeme

Op 6-4-2026 om 23:43 schreef Graeme Geldenhuys via fpc-devel:

Respectfully, I disagree. Time-based releases don't solve anything in the current FPC context.

It works for a few large and heavily sponsored projects with heaps of grunts that continuously do release engineering work anyway for their corporate masters' internal trees. Then you only have to pick a moment, and that might as well be on a clock, or by lobbing an arrow at a dart board.

But not necessarily in fixes. And this up to date bringing of fixes is one of the bottlenecks, together with primary reason, the migration to GIT. (*)

As said the prerequisites for time based releases are not furfullled by FPC, where very little release related action happens outside release periods when releases are being prepared outside of my bulk merging of non compiler revs.

Having time based releases would only have delivered years/(frequency_per_year ) carbon copies of essentially 3.2.2. Specially compiler bugs are hardly merged outside of release preparation periods. (say a dozen out of 6000 compiler related revs difference between main and fixes. Not all will be relevant in 3.2.x context, but a dozen is very low bar)

Yes, some build automation _could_help save some minor time, but this doesn't yield any speed up in the current release process, because the problems are in the actual content creation for the 3.2.x branch. Not in the automatized building.

The actual release building phase is usually only one week (one or two weekends) for a minor release.

(*) We still have to see if the improvised merge tracking can also be easily used for tracking between fixes and release branches. Things that used to be simple are now manual and complex with GIT. Florian already mentioned the submodule problems.

This is not correct.

But we depend on the person assigned to the task. Florian has the task for 3.2.4. He will testify that I prompt him about it regular as clockwork, since years.

If Florian agrees, and there is someone out there that wants to tackle the task instead of Florian: contact me, we'll set it up. I'll give the necessary rights on gitlab and so on.

After that:

I have been waiting for 3.2.4 to go out the door before proposing a time-based release schedule.

The advantages of time-based releases are clear. By only including what is considered stable/tested, we hopefully avoid a lowering of quality.

A new version based on trunk will of course be more risk, but that is inevitable.

I am not active on the forums, but if there are people interested in tackling the task there, tell them to contact me, and we'll see about getting 3.2.4 out of the door and setting up enough CI/CD to make regular releases effortless - at least for the major platforms.

I'll see if we can provide some monetary compensation for the task, from the FPC & Lazarus foundation.

If Graeme wants the task (which you seem to imply): we've cooperated before and I'll be glad to do so again.

Michael.

Timed releases make perfect sense in any context:

Whatever is in, is in. What is not, goes in the next release.

It's like a train schedule:

If a fix catches the current train, great. Else it takes the next train.

in the end all fixes reach the destination:
The users get their desired updates on a regular basis. Maybe not in this, but then in the next release.

Michael.

First of all, I have no insight on the workflows of the FPC team... But, IMHO with git, this should (have) become easier.

Of course, not on its own.
And certainly not **IF** the merging is done by a small group (subset of the team).

But, with git everybody should become part of it. Ok, well not everybody will feel comfortable enough, but that is solvable, if at least half of the team has the "git knowledge" (and willingness).

Everyone should make a **pre**-selection of their own commits in terms of merge or not. That hardly takes time. And (very most likely) whatever current system is in place, can run from that pre-selection, with heavily reduced amount of work. (and less merge conflicts).

That may be to late for the current branches. But for going forward there would be ways.

Florian already mentioned the submodule problems.

Leaves the question why they are not re-organized.

Except for some historical svn order, I never understood why FPC-Build is the top level, and fpc-source is a sub-module within.

**For an outside observer**, everything says that (if using submodules) then fpc-source should be the main repo, and fpc-build should be a submodule. Yes, I can see that the dependency can be argued either way... Anyway that isn't my call to make...

Martin Frb wrote

On 07/04/2026 10:41, Marco van de Voort via fpc-devel wrote:

.
.

Changing the dependency direction wouldn't solve the issue (regardless from the direction, the problem is still there), but it would result in breaking the Makefiles and thus more work (especially considering that some of the Makefile parts are used only by one or two targets and thus people potentially trying to adapt the Makefile to a new structure might easily miss those parts).

Tomas

Op 7-4-2026 om 10:59 schreef Michael Van Canneyt via fpc-devel:

Timed releases make perfect sense in any context: Whatever is in, is in. What is not, goes in the next release.

That's a snapshot, not a release.

It's like a train schedule: If a fix catches the current train, great. Else it takes the next train.

With a train, they are staffed and sometimes even cleaned when they roll into the station.

It is an organised endeavour, not a mindless robo-act.

Moreover, even if, it would only work for minor releases.

IMHO there would be robobuilds of fixes releases without much content, and it provides no solution for releasing the first release of a  branch at all.

If this all were this simple, nobody would complain about releases, and just use trunk/main snapshots.

Marco van de Voort via fpc-devel kirjoitti 7.4.2026 klo 11.41:

 Florian already mentioned the submodule problems.

Years ago when studying Git, I tried to understand submodules. I did not find any valid use case for them. They were somehow weird in every situation. I don't remember details but partly for that reason I never used them myself.

Get rid of submodules in FPC sources and those problems go away.

Juha

Op 7-4-2026 om 11:01 schreef Martin Frb via fpc-devel:

For me it is about the same, if you don't count that merge tracking was not out of the box, but crafted by Florian with scripts and a requirement to merge with -x.  That took over an year to gestate, and has been down for periods.  Still, it is workable. I still have to build a filter for the fpcbuild repo, something I planned for the coming weeks, now that I have more time again.

As far as merging goes I'm not as versed in solving if something goes wrong with GIT as with SVN, so I shy away from the larger merges, but that will improve a bit with time, with some unresolved cases remaining (GIT can simply go wrong more easily and is more complicated in general)

But I currently can't branch a release branch from fixes and maintain it while last minute fixes are delivered. Same but worse for creating a new fixes branch. That's why I stopped being release manager in 2020, and it is still true.

Yes. But that could have been done both with past SVN or current git-with-patchy mergetracking. It simply doesn't happen.

That is the whole problem with all these fantasies (the git migration inclusive), they paint an ideal sunny upland, and then try to simplify the whole issue to "if we just cross this bridge, the problems will be gone away". But the devil is in the details, and it is usually the human factor. The big changes are only goal posts to nail policy too, they don't solve anything in itself.

To be fair: merging in the compiler is harder than what I do , since things are more interconnected there.

That hardly takes time. And (very most likely) whatever current system is in place, can run from that pre-selection, with heavily reduced amount of work. (and less merge conflicts).

That's what I still do occasionally, merge a large section of the non compiler revisions in order. Currently around a x.y.4 point that gets a bit harder, and certain categories are not the past it was mostly intertwinement of must have new mysql connectors with fcl-db restructures.   In this cycle I ignore nearly everything "web" related categories (fcl-web/js/json, fcl-passrc(due to pas2js) and many, many more packages that I hardly know) because the very high number of intertwined revisions, and a lack of overview of the status of these packages. I assume only Mattias and Michael know anything about them.

That may be to late for the current branches. But for going forward there would be ways.

Yes. And it happens. Sven, FPK and Jonas all merge some of their revs. But at a very, very low rate, and mostly really short revs only.  I think only Pierre might fit the description better.

> Florian already mentioned the submodule problems. Leaves the question why they are not re-organized.

Because we were told that git solves all problems and can do everything (;-)).  It was all so simple and modern, and contributors would magically appear from all corners of the internet, and pink unicorns would run through its streets and fart perfect code. (ok, I made that last bit up)

However during the year before the migration very few of the identified problems were solved, except merging pre SVN era history to form a large, mostly continuous history.

Submodules, merge-tracking, nothing was ready when the transition was forced through, and at a very late point (when migration to GIT changed to migration to gitlab, the bugtracker was also thrown under a bus).

A workaround solution for merge tracking took another 1 1/2 year. GItlab only allows to save views on the bugtracker for a few months now.

Merge requests, that were hailed as the magic bullet that would speed up the pace of development.

Well, merge requests is  the original subject of this thread. One can argue if they are a netto plus or not, but there are downsides too (it allows users to submit more code at once and without prior communication to core about formatting and other decisions), and in any case they are not the game changer they were hailed to be.

(I think they are a netto plus, but a rather small one)

I assume that some changes were also postponed to the next release round (i.e. pacing the gitlab changes), not realising the gap that would build. The same happened with the SVN migration.

Except for some historical svn order, I never understood why FPC-Build is the top level, and fpc-source is a sub-module within.

fpcsrc is roughly the shipped source archive, fpcbuild is everything else + the other submodules like documentation.

But fpcsrc and fpcbuild both need to be mergetracked. Documentation afaik isn't,.

Maybe some of the decisions were also influenced by gitlab limits on the number of repos if you didn't get the open source status.

**For an outside observer**, everything says that (if using submodules) then fpc-source should be the main repo, and fpc-build should be a submodule. Yes, I can see that the dependency can be argued either way... Anyway that isn't my call to make...

See above, things were rushed through, and all details were deemed solvable with git(lab). Any opposition was ridiculed as the way of dinosaur.

Anyway, if we reverse the order, then if I understand everything correctly  we would have the robo commits to advance the fpcbuild submodule link in the fpc/ repo ? No thanks!

If I understand the problem laid out by Florian correctly, a sane solution would be more to have a new root repo that only has submodules. (fpcbuild , fpdoc, fpcsrc). Then the history of that repo doesn't matter.

But that would require some makefile and scripting rework in fpcbuild to handle the change directories.

We're talking about building a release at regular intervals.

If we limit what goes in, testing will be reduced to minimum, making it perfectly doable.

If of course we mindlessly merge in whatever pops into our head, we're in for a bad ride.

That a major release is more complicated does not diminish the value of regular releases for the user in any way.

Michael.

Well, what I can say for myself (slightly modified for those less git experienced). If I make a commit, that I deem might be a fix => I can immediately make a local cherry pick.
If there are conflicts, they will be best solved when my memory is fresh, and in doubt I write the changes anew into the cherry pick.

I don't have to push that. I can keep it until I know I want to push it. (I can also push it elsewhere and ask for review). If there is other incoming on the branch, while I haven't pushed, the conflicts with that are usually smaller.

And if you need a final selection, you can cherry pick from the cherry picks...

IMHO git offers some small additions over SVN here. But the real advantage only comes if everyone participates.

Those less experienced can ask for their commits to be merged by others in the team. If done regularly that will be a minimum burden. They may still need to answer and be involved if there are conflicts.

To be fair: merging in the compiler is harder than what I do , since things are more interconnected there.

Which imho makes it even more important to merge/pick "potential fixes" asap. Once you start forgetting all the nitty gritty of your change, picking them becomes much harder.

If needs must, pick into an intermediate branch, and pick a 2nd time later.

Well, unicorns need a handler that guides them. ;)

They are on the attract others side...

Though, there is a need "trick" to deal with older MR (also can be done for patches and all).

Apply them to a revision of the time when they originated, then rebase them forward step by step => each time you get to solve a small set of the conflicts. It does take longer, but you see the smaller conflicts that may be easier to identify how to solve (not always / sometimes)

Anyway, if we reverse the order, then if I understand everything correctly  we would have the robo commits to advance the fpcbuild submodule link in the fpc/ repo ? No thanks!

Ideally the would be part of the commits that would make them a requirement.

Well depends...

If FPC-build changes to accommodate a new version of "make" then yes. But, if you add stuff to fpc-source that needs changes in the build process, then that should be one commit.

The robo-commits basically signify that they are one single repo. The split is arbitrary, the could be all in one git repo.

There are very few commits to fpc-build (other than the robo ones). And how many of those real commits are because a commit to fpc-source made them necessary (and therefore the reversed submodule update in fpc-source to pull a newer fpc-build) could have been part of the overall commit?

But then again, as I don't use them, I really don't know all the requirements...

Op 7-4-2026 om 13:13 schreef Michael Van Canneyt via fpc-devel:

> > It is an organised endeavour, not a mindless robo-act. We're talking about building a release at regular intervals.

The fixes branch as is yes. And I said that the problem is making sure things to be released *are* in the fixes branch.

If we limit what goes in, testing will be reduced to minimum, making it perfectly doable.

Current minor releases are also doable. It just needs to be done.   With the same attitude as now, that leads to empty releases just because the timer ticks.  The work overhead per actually delivered fix to the user only increases.

This was basically the situation before I started working on releases in 2.0.4 times, and it doesn't work.

Making fixes releases with a handful of emergency fixes, only wides the gap between fixes and the next major release even more, which results in unusable .0 releases and you still don't resolve most the frustration with the current scheme.

Namely that users have to wait a long time (till the next major release) before they see a fix back in a release.

Just saying that you have recently essentially rebuilt the last release with a few fixes won't make that go away.

The problem is the human factor, not policies or build technology, but actually executing the policies and using the tools that are there. Time based or old style doesn't matter.

If you manage to accelerate that (and more often releases leads to more polishing of the details of the process), you might actually change something with the release schedule. Pinning all your hope on near empty robo builds to circumvent the human factor won't.

Op 7-4-2026 om 13:36 schreef Martin Frb via fpc-devel:

Well, what I can say for myself (slightly modified for those less git experienced). If I make a commit, that I deem might be a fix => I can immediately make a local cherry pick.

If it is a pure fix, maybe. If it is part of a restructure, that is harder.

I don't have to push that. I can keep it until I know I want to push it. (I can also push it elsewhere and ask for review). If there is other incoming on the branch, while I haven't pushed, the conflicts with that are usually smaller.

I hardly can leave commits in local repos for long, as I work on multiple machines, so that would not be an option for me.

Yes, I know I can invest an insane amount of time to interface it via my own gitlab repository, but that would only be more work, both in setting up as in daily use.

IMHO only if you fully follow the git suggested workflow to the letter. As soon as your workflow situation differs, the whole thing comes crashing down. IMHO git has the doubtful attribute of being both too flexible and too inflexible at the same time.

There is IMHO still a big difference between immediate and after a few weeks. The need for immediate merging action without first seeing how it fares in main is IMHO too limited.  That is the whole idea of having two branches.

There are a handful of regular fix submitters (among others Margers, Rika, AlexTP, Gareth as the most frequent) that deliver to the point fixes.  And maybe it is easier that way than the old way of giving them commit bits with some warnings (like don't commit outside of your expertise without review).

That is the netto plus saving some commit account administration maybe, and a bit of control/oversight. But that doesn't really broaden the contributing developers as much as often was predicted.

So I stand by my conclusion that it is not  the landslide feature as it was made out to be.

Though, there is a need "trick" to deal with older MR (also can be done for patches and all).

Yes. Roughly the same trick as with old style patches too, together with manually removing often conflicted but trivial bits like Lazarus projects and makefiles.

How do you enforce that? A post commit script at gitlab that updates and the squashes the commits into one?

The robo-commits basically signify that they are one single repo. The split is arbitrary, the could be all in one git repo.

I think the main reason is to be able to check out the multiple repos (that are IMHO separate administrative units) as one checkout with one branch name. E.g. for release and snapshot scripting. Also in the past, fpcdocs was versioned, that might also have been a factor. (the fixes fpcbuild links to the fixes docs).  You could switch the version of the docs on a per branch basis (for trunk-fixes-release candidate-release).

I might be doing something wrong but iirc this didn't work for me on windows for RC1 and ended up  hand copying repos in each other to get a buildable complete tree, so the current situation is not ideal.

Anyway I'm not entirely sure what the original reason was.  I wasn't much involved in the early SVN migration on an architectural level, more on keeping things going, like I'm now with git.  But I used a much larger subset of SVN than I ever did of CVS because of the merge/release work and  the various packages/ restructures. SVN felt an improvement pretty quickly (if only because renaming files was easier)

If git is too inflexible, I rather would lean towards adapting those scripts for multiple checkouts than stuff everything in one repo. But that depends on my guestimate on the reasons, and might require careful synchronizing branch names between repos, so that you can check them all out with one branch name.

And as said I think there was an element of pacing the migration changes but that petered out.

There are very few commits to fpc-build (other than the robo ones).

That's because there have been no releases. It usually picks up around release time and during the year that a major branch is in beta.

... but I agree this could all be overcome if the submodule construct is too hard over time. It is from a different magnitude than e.g. the merge tracking.

It should still be "simpler right then, than at any time later" ?

**If** you decide it gets picked, then at some point you have to do the work of picking it.

When you "just" (recently) written it, and still remember the decisions for the little details, then it should be easier, that it will be when you return to it later.

Worst case, you have to (partly) rewrite it for the fixes branch (if that is allowed).

Actually, you only need a private gitlab if those machines can't see each other via network (not even at any time).

But yes, its a bit of setup once (I don't call it insane amount, but if its all new to you you may spent a day...)

E.g. I have my laptop and desktop (and all my VM) speak directly to each other.
I do a git pull, on my laptop, it always pulls the official gitlab, and my desktop (if its on, and my laptop is in the home network / otherwise the remote is unreachable).

For VM, I use access via folder. For my laptop I run "git daemon" on my desktop
- spent an hour (2 if there are issues, 3 if you have a firewall that really is acting up) to set up git daemon
- spent 10 minutes to do: git remote add NAME  url
- spend a bit more time to learn setting different remotes to your branches before you push them
If you work with a GUI the last step is easy too.

And, last not least => before you push into an local repo, make sure the branch you push is not checked out. (should give an error, iirc) I solve that by always working on a new branch when on my laptop (or any 2ndary).

I don't think I follow the "so called default" do a lot an the main branch. I hardly use merge, I do plenty rebase instead. ...

Then have 3 branches
- main
- maybe fixes
- fixes

Merge (cherry pick) immediately to maybe fixes. Since that already has none of the "non fix related" commits, you will likely get do to most of the conflict resolving then.

Later, if confirmed, you can cherry pick again. That can have another conflict, but is less likely to have.
You can have a "dummy branch/tag" on "maybe fixes" that you move forward, to the first not yet "merged to real fixes" commit.

It' not a standard workflow. But it should work...

For me "maybe fixes" is my local tracking branch of fixes (so I need to rebase, if others merge to fixes). But 99.999% of times so rebases are fully automatic.
And because I keep it local, I can just remove the commit (skip in rebase).

> They are on the attract others side... So I stand by my conclusion that it is not  the landslide feature as it was made out to be.

well, true. They are still contributed patches.
The possibility to view them online is personal preference.

I don't know the workflow. But lets say I committed a change to FPC sources, that also needs an update in fpc build.
Then I need to make commits to both repos, right? The actual content change in fpc build (required for my fpc src change) does not come from nowhere.

So then, if I made both commits, then it would be my responsibility to change the submodule in the same commit, and push it course, this requires every one to know how to do this. (or do an MR, then someone can take my changes, add the submodule stuff, maybe squash it, and commit it for me)

Yes you want to be able to build any old version (or any branch) => but more point on : any old version. Pick a random fpc-src commit, and you should be able to get the right fpc-build.
That is working right now, or at least it should.

But if you had one big repo with both contents in one, that would work too. And it would work if dependency order was reversed.

But that also show the point.
You want to build a specific version of fpc sources.

You (probably) never start and say: let me build "fpc build" from Jan, 2nd 2024 noon? (eg git bisect) So your start point is to go to the correct fpc source commit (history or branch). And then find the fpc build that mathes.
So that would say, fpc build should be the submodule.

I might be doing something wrong but iirc this didn't work for me on windows for RC1 and ended up  hand copying repos in each other to get a buildable complete tree, so the current situation is not ideal.

I don't use submodule myself. So I don't know how well they really work. (when/where/if you need to give arguments like recurse sub module / and when/how/when to restore when you managed to get them out of sync.

If you do only build TAGGED version (or HEAD of a branch), and you keep your TAGS correct across repos, then you probably don't need the submodules.

But if you go to a random commit in fpc sources, then you need the correct commit in fpc build. And there is no tag.
The submodule will get you there.

Though, having to search the commit in fpc-build, that has the commit xxxx of fpr-src as submodule sounds like a heck of extra work.

If the order was reversed, then when you checked out (recurse submodule) in you fpc-source, the fpc-build should follow on its own.

As I said, I don't use it, so its "in theory"...

That's because there have been no releases. It usually picks up around release time and during the year that a major branch is in beta.

Ok, but then the build / some builds are broken before?

Anyway there is no force to update the submodule link immediately. fpc build (if it was the submodule) could run ahead for a while, and then when a nice point is reached, the pointer in fpc source gets updated. (that means that the fix wont be intermediately visible, but if there have been broken commits for that long, a bit longer wont hurt)

... but I agree this could all be overcome if the submodule construct is too hard over time. It is from a different magnitude than e.g. the merge tracking.

Well, if you have the "cherry picked from" in each commit you can run a script.
If you missed something, worst case you add an empty commit to create a commit message.

But, It wont give you a storage for commits that have been actively chosen for "not to be merged".

Because you have more states, than merged or "not merged"
- not merged
  - not reviewed
  - rejected (unless required by another commit)
  - rejected / blocked
- maybe want to be merged
- merged

not sure if you need a reason for merged
- fix
- dependency

So you need some storage, but you would have had to have that with svn too? Just it changed to sha1 instead of numbers... (which I imagine could trouble some scripts)

"maybe want to be merged" could be a branch of already cherry picked commits. (from which the a 2nd cherry pick can happen into the real fixes). But a text file does too.

Martin Frb wrote

>>> Anyway, if we reverse the order, then if I understand everything >>> correctly  we would have the robo commits to advance the fpcbuild >>> submodule link in the fpc/ repo ? No thanks! >>

Actually, I would think the relation between fpc src and build can be described as n to 1

- For any commit in fpc-src there is one fpc build commit that works (others may, but one that should be used)
- For any commit in fpc-build there are many commits in fpc-source that it can be used with/for.

But because the submodule in the current direction, allows to specify only one fpc-source commit as belonging to the fpc-build commit, you artificially keep creating commits, so you can link to all the other fpc-source commits.

And if you reverse the dependency, that should disappear. You only need the submodule update, when it is technically required.

If the dependency order is swapped, and you commit to fpc source and it keeps building with the same fpc-build, then there is on submodule update needed.

Not really? Most changes in fpc-build don't depend on changes in fpc-src (at least not directly) and vice versa? However, you need to have both parts up to date when building (either a release, or a snapshot, or whatever - depending on the particular branch).

- For any commit in fpc-src there is one fpc build commit that works (others may, but one that should be used) - For any commit in fpc-build there are many commits in fpc-source that it can be used with/for.

It isn't just that it wouldn't build, but that you need clearly defined combination you can refer to (should it be because you want to test building and the point of the test is having a consistent state to which the test refers to, or because you want to be able to refer to a clearly defined point in time in the bugtracker, because there _are_ some cases in which one depends on the other).

No, because you loose the consistency then. You wouldn't test RC building, etc., against a clearly defined state, and you wouldn't know what people used when they report issues.

If the dependency order is swapped, and you commit to fpc source and it keeps building with the same fpc-build, then there is on submodule update needed.

Again, during the release (and their preparations), changes are performed in both (actually, all 3 including fpc-docs) repositories and you need to keep track of the latest (most up to date) state of both / all 3.

Tomas

Ok, then I got that part wrong. So then maybe its to adapt to changes in OS, make, ....

But then that is the point I made, or isn't it.

If you build FPC source SHA xxxx => then you must have FPC build => sha yyyy

But if you have sha build sha nnnn => then there are many fpc-build commits that could be build with it.
At least the fact that many otherwise identical fpc-build commits have all those different fpc-build commits would strongly suggest that.

Sorry, but I don't follow?

If I would check out the fpc-source commit xxx tagged as RC1, then it would have an exact specified  commit in the fpc-build submodule? It would always be build with that, never any other?

But the time at which those changes happen, does it really matter. So long as for any give source-commit there is a specific build-commit. And that specific relationship can be found for the rest of time?

Martin Frb wrote

On 07/04/2026 16:21, Tomas Hajny via fpc-devel wrote: > On 2026-04-07 15:58, Martin Frb via fpc-devel wrote: >> On 07/04/2026 15:41, Martin Frb via fpc-devel wrote:

.
.

Yes, partly (e.g. 3rd party tools and binary data needed to be included with FPC releases for certain targets which don't provide them out-of-box), target and/or Linux distro specific metadata for specific FPC releases (including modified makefiles for complete releases - e.g. including the Windows installer, Unix installation scripts, etc.), but it also holds release specific artifacts like associated readme.txt, whatsnew.txt and faq.txt, used licenses, etc. The main distinction is - you only need this repository when performing release building, there are no .pas or .pp files within this repository.

It isn't that you must have FPC build => sha yyyy (and it wouldn't build otherwise), it is that you always _should_ have the most up to date version of both. It's like saying that you must have FPC RTL >= SHA xxx when building release of FPC compiler >= SHA yyy - while that is true for certain versions, you simply don't want to include random (although technically "valid") combinations of FPC RTL and FPC compiler sources in the release process, because you want to be sure that two people building the release should always use the same combination. And if you want that for the release, you also want to have that when testing the release building process.

But if you have sha build sha nnnn => then there are many fpc-build commits that could be build with it. At least the fact that many otherwise identical fpc-build commits have all those different fpc-build commits would strongly suggest that.

You probably have some typo there (fpc-build x fpc-build), but I hope that I clarified the point above.

Yes. But preferrably, you want to be able to test that already before tagging (remember - there are _many_ different targets and the target maintainers should test their building even before tagging!), and also after tagging (testing the release building after needed fixes coming from the RC testing are applied).

I'm not sure if I understand what you mean here. The point is to provide anybody testing the release building (or performing the release/RC build) with a consistent combination of all three sources for the chosen branch at any point in time.

Tomas

I don't want to paste a wall of text. But I find it useful to explore these ideas via LLM:

For a large compiler project which depends on other git repositories, should submodules or subtrees be used? What is the difference? Also some massive projects use external tools like Google's repo tool or Zephyr's west to manage many related repositories via a manifest file, bypassing Git-native submodule/subtree limitations. But that adds another dependency. What are the advantages and disadvantages of using an external tool with a manifest file?

The Free Pascal project (https://gitlab.com/freepascal.org/fpc) formerly had a development workflow based around SVN. They have migrated to GIT, but the workflow needs adjustment because there are many uncommitted merge requests and new compiler releases have stalled. Other large and successful projects using Git include the Linux kernel and the Rust language and compiler project. Other large compiler projects like LLVM and GCC also migrated from SVN. What can we learn from these projects about development and git workflow strategies that work well? What parts of the Free Pascal development and Git workflow should be examined and possibly changed? Keep in mind that reasons other than the workflow might also be causing the lack of progress. What other reasons might be the cause?

Op 7-4-2026 om 18:09 schreef Wayne Sherman via fpc-devel:

Well, I'm not an AI, but considering the examples I'd say "get multi billion sponsoring". The fact that the AI doesn't pick up on such glaring differences IMHO says enough. One could argue about the usefulness of AI, but opinion pieces are not one of its strengths.

The AI graciously compares projects where paid employees of big tech companies do the grunt work with grassroot projects like FPC and Lazarus.

That's also the problem with the time based releases suggestion. That is another hand-me-down policy of such projects to ours, and the circumstances are vastly different.

Ok, but then you could update the submodule (with either being the main and the other the sub module) just before that time... Currently it is done several times a day. I would guess there aren't release related works or testing on the main branch at current?

And so then, right now (on the main branch) would apply to use the latest of both. Anyone can just check them out independently (or force their submodule locally)?

So why is that flood of "Update" commits happening.

----------------------
Mind, given the just keep the top commits together updating, even if it isn't currently in release...

Then yes, if you switched you would have similar commits in fpc-src. Except the last real commit on fpc-build is from February. So outside release cycles (and for the main branch, that would be always), that would mean one "update" commit every couple of weeks?

During releases, on fixes I take your word it would be more frequent. Still, would it hit 3 a day, almost every day?

The question is, how to you find the matching pair...

Well for a release it is easy => you go to the tag. The tag in fpc-build will be conveniently set such as it gets you the correct fpc-src too.
Of course then, if you go by tag, you could just have the same tag in both repo, and you would not need submodule relations...

But if you say, you tested with fpc-src ABC123 => and you ask someone else to test with the same...
How does that work, they can't just check out that commit, they need the fpc-build commit that is linked to it.
So they need to go to fpc build. They need to search the fpc build commit that will check out fpc-src ABC123....

Or (probably?) you never say, please test fpc-src ABC123 => instead you say please test fpc-build FDE321.
Is that more convenient to do all work based on the fpc-build commit?

I mean currently yes, but if the relation was the other way round, if you could say
Please test with fpc-src ABC123 => and switching to that would load fpc-build FDE321 as submodule?
Would that be worse?

Yes, but see above. If the dependency order was changed, you could still switch to an exact pair of the two.

You just have to identify them by the fpc-src sha1, instead of the fpc-build sha1.

As I see it, from all I gathered, for just being able to identify an exact pair/combination => either way works. The current works, of course it does. But switched also would work (well maybe I still miss something). The questions is/are just
- are there advantage by identifying the pair from the one or the other?
- would a monthly or bi-monthly "update" in fpc-src (and some during release preparation) be worse or better than 3 per day on fpc-build?

So fpc doc then also would need to be a submodule of fpc source. Well, not sure nested submodule in fpc-build might work too, but has no advantage.

Question is how many "update" commits fpc doc then triggers.

I guess docs are updated independent of the changes that triggers there change (i.e. adding a property will not add the docs, the docs come later)? Then the "update" of the submodule would only be needed when release testing starts?

---------------
Of course if it really is ONLY for combining the 3 repos for release build (including test builds of that) then you could have an empty repo, that just has all 3 as submodules.

It would not have automated updates. Whoever want to start a release build (from HEAD) will do one update, and can then ask others to use the fpc-rel-group sha1 for their tests.

Wayne Sherman wrote

I find it useful to explore these ideas via LLM:

Git submodule / subtree / external tool:
https://chatgpt.com/share/69d5305c-b9d8-83e8-8e89-092cef87c0ea

FPC development workflow, migration from svn to git, other reasons besides workflow
https://chatgpt.com/share/69d5345f-3c88-83e8-961d-64e185d2d8e5

Op 7-4-2026 om 15:58 schreef Martin Frb via fpc-devel:

Not necessarily. The counterexample is that fpcdocs is updated without a corresponding fpcsrc during release times when
there is an last minute emergency doc fix.

So while I don't subscribe to your analysis, I do think it is mostly about maintaining the link between the various repositories, specially for branches that end (RC, release).  So maybe if GIT is incapable, a continuous link is too much trouble.

Having a dummy root repo would work around the GIT deficiencies. The branches of that repo would double as the "universal" branch moniker, and the robo updates for living branches like fixes wouldn't hurt, as its history would be pretty much never needed.

And if you reverse the dependency, that should disappear. You only need the submodule update, when it is technically required.

That is correct, but only for the steady state between releases when fpcbuild is mostly dormant. But it doesn't fix the more frantic times during release (and then special major-). And it is then, in times of relative chaos that the automated links proves its worth.

Just to be clear, i do not have commit access, i just use the main branch because i find it stable enough for my uses (and provide some functionality i find useful) and in general whenever i use some FLOSS project that i may submit patches to, i prefer to use the development versions as i find them more appropriate to submit patches against than release versions. I do not have any special access to FPC other than what everyone else has.

Kostas

Martin Frb wrote

On 07/04/2026 18:03, Tomas Hajny via fpc-devel wrote:

.
.

No, it would be basically the same - except that you'd have to adapt the Makefiles to this change (and it isn't easy to do due to different parts only used on certain targets and thus not easily tested by one person).

Yes, but see above. If the dependency order was changed, you could still switch to an exact pair of the two.

Indeed.

No, the only advantage of not changing the direction is that you don't have to modify the Makefiles. Well - technically, you wouldn't have to modify it if you created fpcbuild and fpcbuild/fpcsrc subdirectories within the original fpc-src repository, and move everything from the original repository under the newly created fpcbuild/fpcsrc/ subdirectory (and obviously move the top-level Makefile from fpcbuild to fpcbuild/ in the fpc-src repository). That should allow keeping the Makefiles intact while changing the dependency direction, so this would be an option as well - if considered as an important improvement compared to the current situation.

- would a monthly or bi-monthly "update" in fpc-src (and some during release preparation) be worse or better than 3 per day on fpc-build?

_Much_ worse - basically unusable for the original purpose as already explained by Marco in his yesterday's response.

_If_ we need to make some changes in the repository structure and _if_ there's no (reasonable) alternative solution allowing us to keep the current layout by using a different Git technique (I'm by no means a Git expert), then I'd prefer either converting everything to a single repository (with the potential disadvantage / change of having fpcdocs branched as well and another disadvantage of having 3rd party binaries with FPC sources within the same repository). The idea of an empty top-level repository importing all three parts (fpc-src, fpc-build and fpc-docs) while keeping the original directory structure _and_ keeping the automated updates from all the three repositories (!) would be OK from my point of view as well, but I don't see how that differs from the current situation of fpc-src and fpc-docs imported to fpc-build - however, I might be overlooking something important.

.
.

No, this last part wouldn't fit - again, see Marco's comments in his last e-mail yesterday.

Tomas

Fully agree I tried them too. They are terrible!
G.

FWIW Git submodules are useful for external dependencies to projects that evolve independently. For example say that Lazarus' FP-GUI widgetset manages to become usable again, it could use a submodule to track the last known working commit in the FP-GUI repository to make it a subdirectory under the FP-GUI LCL widgetset that the widgetset can use directly -- then if you break the FP-GUI API, it wont affect the FP-GUI widgetset because when people check out the Lazarus source code, they'll still get the commit that was deemed 'working'. This way the two projects can continue evolving independently without having to worry about imposed work from backward incompatible changes (at least not immediately, which is important for something that may not see much developer support for months if not years).

The annoying part of submodules is that they are *too* manual, e.g. if you change branch/HEAD/whatever it doesn't update things automatically to point to the "proper" references and you have to do things by hand. As usual, Git has an awful UX.

Of course this isn't the only way to solve this, e.g. subtrees or plain old "just copy the files over" will do the trick (AFAIK subtrees are basically automating that).

Kostas