[fpc-pascal] CheckSynchronize

[Jonas Maebe]

On 21 jun 2007, at 20:52, Marco van de Voort wrote:

>> On 21 jun 2007, at 20:30, Marco van de Voort wrote:
>>
>> Afaik everyone who is needed for release building is still available
>> in the last week of July.
>
> True, but rushing wouldn't do the release any good IMHO.

I don't think the end of July is rushing it, as that was the original  
plan afaik. And if we delay the release, I think it's quite likely  
that more such patches which are critical to certain groups of people  
will pop up. The whole point of a release is to cut that off at some  
point, let things settle down and get it out of the door.

>> 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).

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 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.

And there probably quite a few more patches which are quite vital to  
several groups of people.


Jonas