> On Sept. 20, 2016, 12:29 p.m., Marco Martin wrote: > > -1, would mean one code path/build config option to maintain for us > > Andreas Sturmlechner wrote: > I would understand if Plasma did much more with Baloo. But I don't see > that right now, it enables two rather isolated modules. While the config > option can be revoked any time in the future should it become impossible to > support, there are machines right now where the presence of Baloo does not > make sense at all.
That may well be the case, but Marco (and I agree with him) argues that we don't want increased maintenance and support burden, since we're already spread thinly. A compile-time option causes this overhead, and that's the reason why it's not popular among developers. - Sebastian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128956/#review99320 ----------------------------------------------------------- On Sept. 20, 2016, 12:06 p.m., Andreas Sturmlechner wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128956/ > ----------------------------------------------------------- > > (Updated Sept. 20, 2016, 12:06 p.m.) > > > Review request for Plasma. > > > Repository: plasma-workspace > > > Description > ------- > > https://mail.kde.org/pipermail/kde-frameworks-devel/2016-September/037734.html > > Regardless of the current state of Baloo, it is not very deeply tied into > Plasma. Usage in plasma-workspace comes down to providing the baloo runner. > > > Diffs > ----- > > CMakeLists.txt 9da918358bd797b8fe00de646b6576ba22976d0e > runners/CMakeLists.txt 48cc3799f834a57031ae387a35f41859178fe317 > > Diff: https://git.reviewboard.kde.org/r/128956/diff/ > > > Testing > ------- > > Several days of Plasma-5 without any issues. Usage of krunner without any > segfaults. > > > Thanks, > > Andreas Sturmlechner > >
