Status of FPC 3.4.0 or FPC 4.0.0 [major release]

[robert rozee]

The main problem is that we don't have a release manager with sufficient time.

This is a straightforward and clear response to the topic.

but what happens when the release manager finds it necessary to direct the core developers to stop working on adding features, and instead direct their efforts to fixing bugs?

it seems that after much discussion we have just ended up back where we started!


cheers,
rob   :-(

[marcov]

but what happens when the release manager finds it necessary to direct the core developers to stop working on adding features, and instead direct their efforts to fixing bugs?

The release manager only manages release branches, not trunk/main.   

[ccrause]

The main problem is that we don't have a release manager with sufficient time.

This is a straightforward and clear response to the topic.

but what happens when the release manager finds it necessary to direct the core developers to stop working on adding features, and instead direct their efforts to fixing bugs?

it seems that after much discussion we have just ended up back where we started!

There are many programmers (as opposed to core developer) contributing patches for bugs.  Since this is an opensource project consisting of volunteers, no-one can be forced to do anything.  However my view is that the release manager should have sufficient rights in GitLab to manage the fixes branch and manage issues and merge requests relevant to the fixes branch.  Of course the RM should also have the support of the core group, since there should be a two-way communication channel to clarify certain issues.  However, the big change I am hoping for is that the RM could ask for community help.  So if there is a few blocking issues, highlight these to the community and ask for help.  With a bit of luck this awareness of issues could focus a competent coder to actually fix something.

[robert rozee]

but what happens when the release manager finds it necessary to direct the core developers to stop working on adding features, and instead direct their efforts to fixing bugs?

The release manager only manages release branches, not trunk/main.

and from where does the release manager obtain (relatively) bug-free code that is of release-quality?

i think we have established that the last time a complete set of release-ready code was available was early-2022, when 3.2.2 was created. since then all new code has been tainted with added features and (as a side-effect) added bugs that diffuse outwards (and potentially widely) from the locale of each new feature as it is added.

bear in mind that said release manager is not a programmer, they are not in a position to fix bugs themselves. and they are probably not in any position to cheery-pick individual pieces of code to mix-and-match to arrive as a release-ready set; more likely all they can do is to try and find a fixed point in time at which a code snapshot can be taken.


cheers,
rob   :-(   :-(

[marcov]

and from where does the release manager obtain (relatively) bug-free code that is of release-quality?

The process is different for major and minor releases. For minor releases you just walk the list of revisions (visualized at https://www.stack.nl/~marcov/mergelogs32/) selecting ones to merge. You also try to keep a list of doable must fix problems that are not simply a merge. (e.g. codegenerator problems like with currency on win64 systems in the previous  3.2 releases)

A good year after the git migration (or 3.2.2 since they were only two months apart), gitlab merging support was implemented (by Florian btw), and I fixed the above website and restarted merging post 3.2.2 revisions to the 3.2 fixes branch till late 2024, when Florian froze the branch in order to prepare a release candidate. 

i think we have established that the last time a complete set of release-ready code was available was early-2022, when 3.2.2 was created.

That would be quite hard as 3.2.2 was released may 20th, 2021. If we could time travel to do our release preparation after the release, our release schedule problems would be significantly less.

since then all new code has been tainted with added features and (as a side-effect) added bugs that diffuse outwards (and potentially widely) from the locale of each new feature as it is added.

And where do you base that on?  What are your test experiences with the fixes branch (3.2.3 ) ?

bear in mind that said release manager is not a programmer, they are not in a position to fix bugs themselves. and they are probably not in any position to cheery-pick individual pieces of code to mix-and-match to arrive as a release-ready set; more likely all they can do is to try and find a fixed point in time at which a code snapshot can be taken.

Strictly speaking release managers are more adminstrative (version system and bugtracker), but in practice you need a good working knowledge what is happening in the project, and be able to talk with the other developers about it. That requires some knowledge.

[plaza1518]

Having someone who acts as a release manager would certainly be beneficial. However:

This is a loose group. Communication within the group is also apparently very “rudimentary.” There are likely only a few close contacts. So far, this seems to have “worked” for most people.

But now the point seems to have been reached where it's “crashing”: long unresolved bugs, Debian (gtk2), qt6, bug fixing vs. new features, ...

And no one can be found who wants to or is able to take on the task of organizing.

The programmers have created a great product that started as a “hobby,” remained a hobby for many for many years, but has actually been used by professionals who depend on the product for quite some time. And now the conflict is there and has erupted.

The core developers need to come together and define goals (and, unfortunately, rules) that they can support as a group. This group will then “automatically” ensure that the rules are followed and the goals are achieved. And the group will also decide when a new release will be made.

Finally, I would like to note that the achievements of all the programmers to date cannot be overestimated. They deserve our sincere gratitude.

[Martin_fr]

Maybe to clarify, from my knowledge/experience (based on stuff in which I am involved / assuming some similarity for e.g. FPC)....

Release management is not (as it may be in commercial env) to manage a list of open bugs, and find assignees for it.

That part is mostly self-driving. Though it has limitations, but then the definition of "bug free" is more a statement of "known regression free, and where available some bugs of prior releases fixed".

Very few bugs outside the "known regression" qualify as blockers. At least long time blockers. They may get a call to attention for everyone. But it is then down to volunteering if someone steps up in time.


However, that definition actually works well for most stuff. Overall, if you have no regression and some other bugs fixed, then the situation has improved.

I am aware there are a few issues (such as some code generator issue) that are not well handled within this concept. But let that be another story.

And for fixes releases, that usually really works well => it comes down to merge and test whatever fixes happen to be available.
Occasionally point out anything needed on top.

For new releases, the trick is to turn them into fixes. Branch them, and maintain the branch long enough until you had time to
- become reasonable sure on knowing any regressions
- having collected the fixes for them
- not having had any new regression added (since it had become a fixes branch)

All that has worked reasonable well in the past.


On the Lazarus side, the fixes branch is a joint process. Everyone selects their fixes commits for the branch. (And either communicates them, or mergers them themself).

The release then comes down to a heads up, so everyone knows to check there outstanding fixes (and/or ask about any issues they think needs to be addressed). And then release-builders will run builds and tests. If that works, then its done.

[Chronos]

This discussion doesn't lead anywhere as usually because "Only volunteers work on this project. Their time is limited. They can't be forced to do the release. To fix the bugs." So unless project leader collects some money and hire some paid programmers then nothing will change. Only excuses remain.

This is just "a hobby" project. If anyone uses this as a professional tool then one should reconsider his approach and use something better suited. Simply Lazarus/FPC is no match for other bigger projects and programming languages like C#/.NET, Python, JavaScript/TypeScript, Rust and list goes on. There are some smaller projects which are more active than this project. So it is just about people.

Perhaps one solution would be to replace people with AI agents If there is not enough manpower then just use unlimited AI agents.
For example Kimi-K 2.5 can use agent swarms https://www.youtube.com/watch?v=FfCqINSD8Tc
Just give them a task like make a new release. Implement Gtk3/4 for Lazarus/FPC and voila here you have it. It is just about right prompt
AI agents won't complain about not enough spare time or motivation.

So if there are here some people who need to have good Pascal compiler with support for modern technologies then just team up and bring us a new tool. We other passive users would welcome such activity.

[robert rozee]

i think we have established that the last time a complete set of release-ready code was available was early-2022, when 3.2.2 was created.

That would be quite hard as 3.2.2 was released may 20th, 2021. If we could time travel to do our release preparation after the release, our release schedule problems would be significantly less.

i've been basing my dates on information obtained from the sourceforge packages page. see:
https://sourceforge.net/projects/lazarus/files/Lazarus%20Linux%20amd64%20DEB/Lazarus%202.2.0/

2nd January 2022 was the earliest "modified" date on sourceforge for FPC 3.2.2 that i found. however upon closer inspection, i see the filename does suggest a date of 9th July 2021. but the exact date doesn't matter too much wrt the present discussion - anything within the range Q2, 2021 - Q1, 2022 is good enough, some 4 years or so ago.


cheers,
rob   :-)

[robert rozee]

as an aside,
    i've never had any problems with FPC 3.2.2 myself, apart from issues surrounding GLIBC symbol versioning (for which i have my own patch - similarly Fred vS and DonAlfredo also have their own solutions). my assumption is that most of the bugs variously referred to elsewhere are very much extreme corner cases that the vast majority of users are unlikely to ever encounter in real-world FPC projects.


cheers,
rob   :-)

[440bx]

@Chronos,

No doubt this project has its share of problems but, AFAIC, the alternatives you offer are rather undesirable. 

Let's see, C#, aside from the fact that it requires using OOP, it also requires .net which is a ball and chain to carry around, not to mention that it pretty much requires VS as a development environment and the resulting programs are slow, use a lot of resources, are clunky and, because it uses .net it is very "sensitive" to using the Windows API.  No thank you.  The day I feel compelled to write binary junk, I'll use C# and .net.

Python, great stuff when you need to quickly produce some code you don't need more than a couple times.   That said, I like its logo. 

Rust ?... I looked into it at one time, I don't even remember anything special about it.  IOW, it sure made quite an "impression".

One of the best FPC features is Lazarus.  In the production of software, while the language is crucial, it is not the only part that is crucial.  The supporting tools are in many ways just as critical and, what I see out there is a lot of pretty software whose usefulness beyond providing eye candy is rather dubious.

If I were to abandon FP, I'd go back to MS C (using the C++ compiler) and VS.  Not exactly something I want to do but, I don't see another really practical alternative (that is affordable.)  Before I do that, I might even customize FPC for my own use.

[Fred vS]

If I were to abandon FP, I'd go back to MS C (using the C++ compiler) and VS.

Okay, but that's only for Microsoft operating systems.

And I don't think there are any problems with FPC under Windows (even better, Windows-ARM now works).

The only problems concern other operating systems and FPC 3.2.2, like OpenBSD, for example, which hasn't been usable for over 5 years (although various patches are available to make it functional),
The same goes for Linux i386 and FreeBSD..

[440bx]

And I don't think there are any problems with FPC under Windows (even better, Windows-ARM now works).

Not quite.  I can't even declare the equivalent structures in Pascal due to bugs in bit fields.

The result of those bugs is records with incorrect sizes and/or incorrect field offsets.  In addition to that, there is no way to tell FPC to align the record when the alignment is greater than 8.

I also want to mention that those aren't the only deficiencies  but, they are the ones currently present in my mind because I've been dealing with them very recently (actually still dealing with them.)

Also worth mentioning, I reported bugs in bit field declarations back for v3.0.4, the bugs I reported at the time were fixed but, either new bugs got introduced or bugs I wasn't aware of remained which are present in v3.2.2.

To add inconvenients, ensuring the Pascal bit alignments matches the ones in the C definition needs to be done manually and, in addition to that, sometimes it isn't possible to make the Pascal definition fully equivalent to the C one. 

Doing this stuff should be very simple and it turns out to be one headache after another, either due to bugs in the implementation or to deficiencies in the language.  It's annoying.  That's when I think about going back to MS C but, that has its own set of downsides I dislike even more (to C's credit, at least they aren't bugs.)

[Chronos]

@Chronos,

No doubt this project has its share of problems but, AFAIC, the alternatives you offer are rather undesirable. 

Let's see, C#, aside from the fact that it requires using OOP, it also requires .net which is a ball and chain to carry around, not to mention that it pretty much requires VS as a development environment and the resulting programs are slow, use a lot of resources, are clunky and, because it uses .net it is very "sensitive" to using the Windows API.  No thank you.  The day I feel compelled to write binary junk, I'll use C# and .net.

Python, great stuff when you need to quickly produce some code you don't need more than a couple times.   That said, I like its logo. 

Rust ?... I looked into it at one time, I don't even remember anything special about it.  IOW, it sure made quite an "impression".

One of the best FPC features is Lazarus.  In the production of software, while the language is crucial, it is not the only part that is crucial.  The supporting tools are in many ways just as critical and, what I see out there is a lot of pretty software whose usefulness beyond providing eye candy is rather dubious.

If I were to abandon FP, I'd go back to MS C (using the C++ compiler) and VS.  Not exactly something I want to do but, I don't see another really practical alternative (that is affordable.)  Before I do that, I might even customize FPC for my own use.

If those alternatives would be better than Lazarus/FPC then I would not be here reading this forum and using it. I work with some of them and they have their pros and cons. But that would be for another discussion topic. It is just useful to do some reality checks and to see how other projects go. But still if there are not enough people to work on FPC then those modern features are out of the table.

The question is how to resolve current issues and for example be able to make stable release once a year. And to keep up with modern technologies. Not just GTK and Qt but also with Windows, Mac, Web (WASM, JavaScript), mobile development Android/iOS/Linux like PostmarketOS and more. That requires significant time and effort from both FPC and Lazarus teams.

[creaothceann]

I might even customize FPC for my own use

It seems that this is the best way to go forward in this kind of environment - making customizations, then submitting them as a pull request