Review Request: ResourceManager: Do not double initalize the NepomukMainModel

[Vishesh Handa]

> On June 26, 2012, 9:55 a.m., Albert Astals Cid wrote:
> > To be honest i'd prefer you commit this to the KDE/4.9 branch after RC1 is released, as you say it's not critical (nothing breaks), so i don't really see the point on breaking the RC freeze.

Oh, you mean one can commit stuff normally after RC1 has been released? I was under the impression that all commits after RC1, till the final release need to go through the reviewboard.

Cool, then I'll wait. And I won't have to add the release team for all my commits.


- Vishesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105281/#review15161
-----------------------------------------------------------


On June 26, 2012, 9:06 a.m., Vishesh Handa wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105281/
> -----------------------------------------------------------
> 
> (Updated June 26, 2012, 9:06 a.m.)
> 
> 
> Review request for Nepomuk, Release Team and Sebastian Trueg.
> 
> 
> Description
> -------
> 
> ResourceManager: Do not double initalize the NepomukMainModel
> 
> The NepomukMainModel is initalized once when it is created and then the
> second time in ResourceManager::init.
> 
> This results in a second connection being made to nepomukstorage, and an
> extra thread being spawned over there. The old thread is eventually
> deleted, but the whole process is rather pointless.
> 
> 
> Diffs
> -----
> 
>   libnepomukcore/resource/nepomukmainmodel.cpp a11faae9a6d42806ba884e74f07e2d0113c6910f 
> 
> Diff: http://git.reviewboard.kde.org/r/105281/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120626/30af4dbe/attachment.html>