[fpc-pascal] CheckSynchronize

Vincent Snijders vsnijders at quicknet.nl
Fri Jun 22 00:17:09 CEST 2007

On Thu, 21 Jun 2007 21:31:59 +0200
Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:

> >> Nobody will dispute that, regardless of when the release is. That's
> >> also not what the discussion is about. The question is whether it's
> >> better to risk introducing new unknown bugs by merging those
> >> particular patches than leaving those known defects in.
> >
> > As opposed to the risk that heavy users like mside and lazarus  
> > start using
> > snapshots/own rolled releases quickly after a release has been made?
> Both approaches absolutely have arguments in favour of them.
> > Because that voids the whole release effort.
> I disagree. I think that at most, it can void the actual packaging  
> effort. The release effort is what enables them to have a stable  
> basis which they can modify with a few known patches to suit their  
> needs. Merging uncertain patches is what, in my eyes, voids release  
> efforts (because you can keep trying to stabilise forever if you do  
> things like that). It's obviously much more preferable if they don't  
> have to do that at all and if it's a make or break point, my  
> preferred option would be a second beta release at the end of July  
> (although in general I would not look forward to making another  
> installation package, another couple months of waiting, possibly more  
> critical patches popping up and possibly delaying again after that).

I value the release procedure very much and that is why I don't want to base a Lazarus release on a snapshot. I see the following options, start with the IMHO most preferable to the least preferable:
A: merge those patches to the fixes branch now. 
B: Second choice, merge them right after tagging 2.2.0, and tag that as 2.2.2 or, that we can use a tagged version for Lazarus releases. 
C: If this is not possible, then I can keep a patch file for fpc 2.2.0 somewhere that I apply before buiding the fpc 2.2.0 version for Lazarus.
D: Tell people that until 2008 these are known issues with Lazarus releases, but that these issues are fixed in snapshots. E.g. having version info and a manifest does not work.

> That said, you are clearly in favour of merging those patches, and so  
> is Vincent. I prefer not to do it, both because of past experiences  
> (as explained earlier), and because e.g. the resources patch already  
> had one unforeseen consequence (which was fortunately not that bad:  
> the version of ld.exe shipped with FPC 2.0.4 apparently cannot not  
> handle the resulting resources).

For the record, it was ld shipped with fpc 2.0.2, so it would not even have been noticed if I made a proper 2.1.5 installation using the binutils from the fpcbuild repository.

And I found about this issue, because I merged this patch to 2.1.5 in my local copy to test it. 

> For all big endian users, merging the set rewrite could also be  
> argued, because without it {$packsets} is completely broken on big  
> endian in 2.1.x (so if you use it in 2.2.0, you have to put {$ifndef  
> FPC_BIG_ENDIAN} everywhere). There are some serious fixes to the  
> threading system which aren't merged (mantis 9016 -- we don't clean  
> up all resources allocated for terminateonfree threads under *nix --  
> that may even be a regression compared to 2.0.4, although a whole  
> bunch of other tthread stuff didn't work at all under *nix/2.0.4 and  
> overall the situation still improved)
> I'm not trying to put up any veto here (nor do I *insist* on having  
> another beta release if they would be merged). I'm just trying to  
> explain my reasons for disliking the merging of them.

Well explained. I think it is clear you want to run minimal risks with fpc 2.2.0. I don't have the illusion that fpc 2.2.0 will have those fixes, now let's see how we can have these fixes in a Lazarus release as soon as possible.
> And there probably quite a few more patches which are quite vital to  
> several groups of people.

Let's gather them in the wiki page. To be eligible, they need not be too large and have to heavy inpact (e.g. merging the internal linker to fpc 2.0.4 would have been too large and I think the same goes for the set handling rewrite).

I want to test them as soon as possible with the fixes branch. I will merge those patches them in the lazarus snapshot packages with fpc 2.1.5, currently win32, win64 and i386-darwin, so testing can start as soon as possible.

Do you want me to mark the version of those fpc executables in any special way? 2.1.5.Lazarus?


More information about the fpc-pascal mailing list