extragear/sdk/kdevelop/app

[Andreas Pakulat]

On 17.04.10 18:52:19, David Nolden wrote:
> 2010/4/17 Andreas Pakulat <apaku at gmx.de>:
> > On 17.04.10 18:04:22, David Nolden wrote:
> >> SVN commit 1115826 by zwabel:
> >>
> >> Integrate the foreground lock.
> >
> > I _strongly_ object to this. Its clearly too late to do this for 4.0. If
> > you want to release kdevelop4.0 with this code, then please do so yourself
> > I'm not going to do that.
> 
> The code that I've committed until now alone does exactly nothing,

Yes it does something, it added a lock in QApp::notify. Did you test nested
event loops? Did you test separate threads with their own event loops? Did
you test sending events to objects in the main thread.

> it just makes the lock available. It is true that I'm just now working on
> actually using it in the duchain to make stuff easier and independent of
> the smart lock, but I guess you're right. Moving away from the smart-lock
> would make KDevelop a much more stable in long-run, but in (very) short
> term it might cause new regressions.
> 
> But why does it bother you so much to have the foreground lock
> available at all? Even if we don't use it to deprecate the smart-lock
> (yet), we can still use it to fix some bugs properly, for example the
> one that caused the huge discussion on kwrite-devel.

Because it doesn't get enough testing. We're not even 2 weeks away from the
release and you're adding completely new code. Thats a risk to our
stability. As I said, its totally fine if you (and others) value this
important enough to do it (including the duchain porting). But I'm stopping
my maintainership around May 1st, wether we release 4.0 at that point or
not.

Andreas

-- 
You will be traveling and coming into a fortune.