[fpc-devel] can r12368 be merged to fixes?

[Joost van der Sluis]

Op dinsdag 16-12-2008 om 17:19 uur [tijdzone +0700], schreef Paul
Ishenin:
> Joost van der Sluis wrote:
> > Op maandag 15-12-2008 om 23:52 uur [tijdzone -0500], schreef Andrew
> > Haines:
> >> It fixes a really terrible memory leak.
> > 
> > No.
> > 
> > Not for now at least. First wait for the testsuite-results (if there are
> > no tests for this particular part, then we even have to wait some
> > longer, as we need users to test it). Then let it settle at least a few
> > days. 
> > 
> > Then we'll see. 
> 
> If it is important then I already tested it after Andrew commit and now 
> using it in the fix compiled lhelp application (where it was visible 
> before and was a reason of this fix). No problems found. And memory dont 
> jump too high as before.

Yes, that's usefull. 

> IMO you are using very high restrictions for fpc packages. There must be 
> less restrictive rules for fixes that does not touch compiler, rtl and 
> fcl or developers will move their packages outside fpc as it is now with 
> LNet. Who needs this?

I don't think that we are restrictive at all for packages. In general
everything is merged. How's that restrictive?

That lNet isn't included with fpc has more to do with the slow
release-process of fpc. This process is slowed down by many reasons,
from which one is that people want that we merge fixes after a freeze.
Which is what we are talking about now.

How can you expect us to merge a change a few hours after it's commit?
We don't even know if the change compiles on all targets, so why should
we even consider merging it? We'll always have to wait for the
testsuite-run on all tested platforms (which is tonight.) 

So in theory we could merge tomorrow. But as we are so close to a
release we know that the change won't be tested very well before the
release we have to e carefull. So give it a few days. But it also must
be tested within fixes, so we can't merge just before we tag 2.2.4.

When this will cause this change to miss the release, we could have a
better look.

But how far do you want to go? If all the releases are already build and
a new patch comes in? Do all the work over? That way we'll never be able
to release a new version again. (for clarity: this is not the case now,
I think this patch will make it, but only the test-results can tell)

Joost.