A.s. the discussion raging now everywhere should be how to accelerate FPC major branches, not optimise the shit out of a fixes release process that, while far from optimal, isn't a reason why you couldn't have releases twice an year. That is all detracting from the real problems.
Most of the current discussions are by people that see the release gap as an easy ride to force through changes that they want because "it will fix the release process".
But the proposals are light on details, and fix any counter with software/scripting that must still be written. Even if it accelerates the first major branch after current main (so the one after 3.4.0), the migration will at first have a delaying effect. I doubt users will really see a better product because of it before 2030.
Ask yourself why after 4 years, the gitlab integration check only checks the compiler, and not the whole snapshot. The gitlab transition was managed by the same people....
Sure, Release has become a problem but maybe this discussion needs to be about the future, not the past ?
I am happy it is moving forward.
Yet I have been amazed by all the reasons about not having a release, which felt like lame excuses to me.
See how Lazarus project does it. The human resources are equally limited.
- First, developers themselves push their bug fix commits to fixes branch, or at least decide which commits are pushed. In SVN times there was a Wiki page where the commits were listed and then a middle man merged them. That was a useless extra step. A developer himself knows the best if his commit is a pure bug fix and should be merged. He must pay attention to the future fixes release while fixing bugs.
That step was not useless, there were reasons for that.
- It was considered a good practice to first test fixes in main for a while, before merging (also think on effects on minor targets and compiler stability is very important)
- Trouble during merging was generally lower when done in original commit order in old branches (FIXES_3_2 is almost 8 years old!). In the beginning conflicts are easily resolved, but any manual intervention creates problems down the line.
- The older the fixes branch is, the bigger chance that some large rearrangement frequently causes problems. In Trunk, some commits changed arguments of hundreds, if not thousands of places from pchar to pansichar. Some additional big commits were about mass fixing Debian lint complaints
- The person doing the fix might not be aware of above differences between branches, specially major rearrangements.
- And then I'm not even talking about fundamental changes in the compiler. They are the biggest reason why only very few compiler changes are backported to fixes
- Lower parts of the RTL are partially tied to the compiler
- And of course obviously there are dialect changes. What if trunk uses trunk features and you merge them back?
- I did a lot of merging in GIT post 3.2.2, and while git merge performance is slightly better than SVN (it gets not as often confused if there are massive changes in other parts of a file), it is not a game changer that matters for maintaining the fixes branch
Why Lazarus used a wiki page instead of simply reviewing the list of eligible revisions, I don't know. It was also possible with mantis (at least in FPC) to set the status of a bugreport as "tomerge", avoiding manual administration. All it required was the bugfixer to enter the revisions into the bugreport and set the status. Easier with gitlab to link those, but not a real gamechanger.
The point of this is that making fixes releases is not the problem, the core focus should be to accelerate FPC major branches to get to at least half the pace of Lazarus. But that means limits on when major features might be introduced and maybe a staging branch for such major features if they can't go into main yet.
The developers don't like to talk about that, because that would mean constraints on their work, and a lot of thinking of releases outside the release cycle. They are much happier to talk about technology that will make all the release headaches magically go away (or at least postpone such constraints and obligations for a while).
So the current discussions devolved into sprinkling gitlab magic on a process that was already not really a problem, with the convenient release gap as a stick to vilify the old process. But the fact is that
everything for RC1 was merged, but Florian simply didn't formally announce it, and didn't follow it up with a release build, or allow post RC1 merges or reacting on release related mails. And all of that process could have happened 1 year earlier too.
The problem is not the process, but that people simply don't execute it.
So those delays have
nothing to with how release branches are prepared. It is the last minute analysis "are we complete?", "is everything buildable?" and the "GO!" that followed it that simply wasn't done. As said usually that has a two times 6 week timeframe for a fixes release (6 wks RC1 and release, but sometimes either one can go faster if no issues are detected) . _IF_ executed.
All these points are deliberately talked down to push forward to more gitlab usage by some vocal advocates. But those advocates point to use in companies and organisations with dedicated branch maintainers to do the grunt work. I really wonder if this will fly long term, specially since the proposals are very light on how it would actually work in practice, and scenarios for when problems come up. Since gitlab doesn't take decisions, it is only a lists keeper.
- The build process itself is now done by Mattias and Martin for 3 major platforms: Windows, MaxOS and Linux (DEB + RPM). I admit I don't know how to do it. Maybe I should study it. There are scripts involved and the binaries are made rather quickly. Clearly building the binaries does not hinder the process.
In SVN times, a Windows release build takes about 2-3 minutes on a Ryzen 5700. Twice that for the x86 - x86_64 combi release (for hopefully obvious reasons). For windows, you do need an innosetup configuration, I assume it is the same for Lazarus. OS X is a black art, but if I understood it right, adapting the constant flux of changes (newer releases, changes in packaging of tools needed for the build, making sure that the binaries are properly signed to pass gatekeeper) are the main complexity, not the build itself.
For the GIT build of RC1 add another 5 minutes to get a proper export of the tree to build in. I don't know how to do that with git (including submodules!), but that might be on me.
FreeBSD roughly the same, maybe a bit slower due to the VMs lower I/O performance.
Now compare that to FPC release. So many artificial problems! For example the excuse that a timely release would be a "snapshot". OK, a well tested "snapshot" can be called a release.
You say they are artificial, but don't even know how Lazarus binaries are really made?
Technically snapshots differ from releases :
- Snapshots are built daily, and are basically a toplevel "make all" in a tgz, so no additional work like innosetup, signing , no documentation, and a few other things. Due to these lower they are somewhat easier to crosscompile on some leased Linux server. In some cases there were multiple such snapshots for development versions (e.g. built with and without optimization).
- For releases the additional things (examples, documentation etc) are added, build conditions are more fixed (-Ur, a certain level of optimization), and more additional packaging(innosetup, signing etc)
For the rest it is just branch preparation, what to release. But for major releases that is the biggy. For fixes less so, and is usually resolved with a RC1, pretty much with anything sane merged, then a 6 week feedback period, and then the final release. Sometimes some build problems popup, usually OSX or iOS, but they are then resolved by giving the maintainer a few weekends time.
So executed tightly (as done for e.g. 3.2.2), that means a 6-12 week release process, most of which is waiting for feedback. Do you now understand why I say that the fixes process is not the problem?
The RC1, RC2 etc. "snapshots" are part of the testing phase. That's what Lazarus project and most other open source SW projects do. Is a release totally bug free? Of course not. Now Lazarus project has 2100 open bug reports. Most of them will be still open when the next release comes out.
It is not about _any_ bugs, but
blocking bugs are more about things that limit an entire aspect of the compiler or new feature. This is specially one of the reasons for slow major branch turnover.
One of the reasons it is this way is Lazarus. Lazarus had a tendency to skip FPC releases (FPC 3.2.0 was the first .0 compiler that was wholly used by Lazarus). You can't want a stable compiler for Lazarus, but at the same time say that we should use a more laissez fare approach about bugs, and say "pity, just wait for the next". That is a bit inconsistent
In addition to that, in FPC the RCs are both for feedback on blocker bugs, and to test the packaging.
Recent
