extragear/sdk/kdevelop/app

[Aleix Pol]

On Sun, Apr 18, 2010 at 8:41 PM, David Nolden <zwabel at googlemail.com> wrote:

> 2010/4/18 Andreas Pakulat <apaku at gmx.de>:
> > On 18.04.10 11:29:31, David Nolden wrote:
> >> The lock within notify only "locks" within the main thread (that's the
> >> expression within the parens), and since the lock is recursive, this
> cannot
> >> lead to a deadlock.
> >
> > Just changed that to not use a global static (yet again). But my
> > question was not wether it can or can not, but wether you tested it? The
> > other thing is that the lock adds useless code which has 0 benefit over
> > the non-lock version unless you start adding code into the background
> > thread that uses it. And that must not happen for 4.0.0 (and IMHO also
> not
> > for 4.0.x)
> I tested it in the sense that KDevelop still works, yes. But now that
> we have it, we might start using it to fix specific bugs. I don't get
> why it should be more dangerous than any other way of fixing a bug, as
> any change is at first "untested". Then you test it, and if it works,
> it's fine.
>
> However, if we only want KDevelop to work with kdelibs 4.4, I guess we
> don't need the lock (yet), and can also revert it. Generally, given
> all the changes that seem to be going on in kate, I think we should
> completely disallow the startup of KDevelop 4.0 together with kdelibs
> 4.5.X, as I'm pretty sure it will be a sub-par experience. We can tell
> the user to update KDevelop, as we may suppoert kdelibs 4.5.x in a
> later release. Else we'll get tons of bug-reports because of kdevelop
> + KDE 4.5 bugs.
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>

On blocking 4.5
-1
I'm using kdevelop against trunk right now and it's not-that-bad (tm).
There's issues but I'm used to issues and there's issues with 4.4 too.

my 5c
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100418/02468aee/attachment.html>