---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116881/
---
(Updated April 8, 2014, 10:30 a.m.)
Review request for KDE Frameworks.
On Tue, Apr 8, 2014 at 7:52 AM, Kevin Ottens er...@kde.org wrote:
Hello,
On Monday 07 April 2014 18:57:25 Aleix Pol wrote:
We started the discussion of splitting some time where we somewhat agreed
on a splitting plan [1]. I've been working during the last week on it,
and
decided I'd
On 08/04/14 11:09, Alex Merry wrote:
Git commit b15084d9316e34462c2508051c6ac89bcf8d77ee by Alex Merry.
Committed on 08/04/2014 at 10:06.
Pushed by alexmerry into branch 'master'.
Revert Replace GPL proctitle code with BSD-licensed code from OpenSSH
This reverts commit
On Thu, Apr 3, 2014 at 8:53 PM, Kevin Ottens er...@kde.org wrote:
Hello,
Hi all,
On Thursday 03 April 2014 09:50:24 Jos Poortvliet wrote:
On Wednesday 19 March 2014 10:41:15 Ben Cooksley wrote:
On Wed, Mar 19, 2014 at 7:15 AM, Kevin Ottens er...@kde.org wrote:
Hello,
Hi,
On
On Tuesday 08 April 2014 22:25:48 Ben Cooksley wrote:
On Thu, Apr 3, 2014 at 8:53 PM, Kevin Ottens er...@kde.org wrote:
Hello,
Hi all,
On Thursday 03 April 2014 09:50:24 Jos Poortvliet wrote:
On Wednesday 19 March 2014 10:41:15 Ben Cooksley wrote:
On Wed, Mar 19, 2014 at 7:15 AM,
On Tue, Apr 8, 2014 at 7:57 AM, Kevin Ottens er...@kde.org wrote:
Hello,
On Monday 07 April 2014 23:27:33 Alex Merry wrote:
Aleix wanted a separate thread for this, so here it is.
The current runtime splitting plan says that ioslaves should be in three
places: core ones (file, http,
See http://build.kde.org/job/kdelibs4support_master_qt5/113/
--
Started by user Ben Cooksley
Building remotely on LinuxSlave - 3 (PACKAGER LINBUILDER) in workspace
http://build.kde.org/job/kdelibs4support_master_qt5/ws/
Running Prebuild steps
See http://build.kde.org/job/kdelibs4support_master_qt5/114/
--
Started by user Ben Cooksley
Building remotely on LinuxSlave - 3 (PACKAGER LINBUILDER) in workspace
http://build.kde.org/job/kdelibs4support_master_qt5/ws/
Running Prebuild steps
Hello,
On Tuesday 08 April 2014 12:30:44 Aleix Pol wrote:
The rationale is that we should never need to pull a Plasma Workspace to
get an _application_ running.
I'd argue the application is broken if that happens. :-)
A regular application should only need KDE Frameworks and eventually other
On Tue, Apr 8, 2014 at 12:55 PM, Kevin Ottens er...@kde.org wrote:
Hello,
On Tuesday 08 April 2014 12:30:44 Aleix Pol wrote:
The rationale is that we should never need to pull a Plasma Workspace to
get an _application_ running.
I'd argue the application is broken if that happens. :-)
A
On Tue, Apr 8, 2014 at 12:27 AM, Alex Merry alex.me...@kde.org wrote:
Aleix wanted a separate thread for this, so here it is.
The current runtime splitting plan says that ioslaves should be in three
places: core ones (file, http, etc) in kio, other useful ones (archive,
bookmarks, etc) in
On 08/04/14 12:21, Aleix Pol wrote:
Given that premise, would you suggest having kurifilter-plugins in this
repository as well?
We can have a kio-extras repository with KIO::everything in it.
That seems reasonable to me.
Alex
___
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117435/
---
Review request for KDE Frameworks.
Repository: frameworkintegration
On Monday 07 April 2014 23:27:33 Alex Merry wrote:
Aleix wanted a separate thread for this, so here it is.
The current runtime splitting plan says that ioslaves should be in three
places: core ones (file, http, etc) in kio, other useful ones (archive,
bookmarks, etc) in kioslaves, and
On Tuesday 08 April 2014 07:52:24 Kevin Ottens wrote:
I agree there's one repository too many. But that's clearly workspace stuff
to me.
We discussed this a few weeks back and decided that we do not want those
ioslaves in kde-workspace, we are not going to maintain them and we do not
care of
On 08/04/14 14:02, Àlex Fiestas wrote:
I personally do not want to have those not of interest or unmaintained
kiosalves around, I do not want to maintain them, I do not want distros to
ship them by default (which will happen for those distros that will pacakge
the entire repository) etc.
On Tuesday 08 April 2014 14:31:51 Alex Merry wrote:
On 08/04/14 14:02, Àlex Fiestas wrote:
I personally do not want to have those not of interest or unmaintained
kiosalves around, I do not want to maintain them, I do not want distros to
ship them by default (which will happen for those
Hello everyone,
This is the minutes of the Week 15 KF5 meeting. As usual it has been held on
#kde-devel at 4pm Paris time.
Were present: agateau, apol, mck182, notmart, tosky and myself.
* agateau put more work on translation support for Qt-based frameworks;
* he fixed string extraction from
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117435/#review55229
---
autotests/CMakeLists.txt
On Tue, Apr 8, 2014 at 1:55 PM, Alex Merry alex.me...@kde.org wrote:
On 08/04/14 12:21, Aleix Pol wrote:
Given that premise, would you suggest having kurifilter-plugins in this
repository as well?
We can have a kio-extras repository with KIO::everything in it.
That seems reasonable to
On Tuesday 08 April 2014 14:31:51 Alex Merry wrote:
Well, I would say: discard them or include them. I know Albert was
pushing not to get rid of code that still technically works, but I think
you either have to go that route and put it in
kioslaves/kio-extras/whatever (so that it will
On March 24, 2014, 3:41 p.m., Alex Merry wrote:
The correct solution is to get drkonqi merged into kcrash (see
http://community.kde.org/Frameworks/Epics/New_Runtime_Organization).
Aleix Pol Gonzalez wrote:
Agreed. If somebody has the time, it would be interesting to figure out
On Tuesday 08 April 2014 17:09:53 Aleix Pol wrote:
Right, I updated the runtime splitting wiki page with this [1], by delaying
to the futurible maintainer of the kio-extras the decision of what
kioslaves to deprecate.
Good move.
Pushed me toward looking a bit closer to this page, as obviously
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117435/
---
(Updated April 8, 2014, 6:14 p.m.)
Review request for KDE Frameworks.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117437/
---
Review request for KDE Frameworks.
Repository: kcoreaddons
Description
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116881/#review55243
---
Ship it!
Ship It!
- Michael Pyne
On April 8, 2014, 8:30
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117440/
---
Review request for Documentation and KDE Frameworks.
Repository:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117437/#review55244
---
Ship it!
Ship It!
- Alexander Richardson
On April 8,
Hi,
I understood that, I just do not know all the other things we need to do
to make NMQt/MMQt part of KF5. And yes, I agree in making NMQt/MMQt part of
KF5. The other doubt I still have is where _kde_add_platform_definitions
is defined. By what I could figure out it is not in ECM, so something
On April 7, 2014, 3:27 p.m., Kevin Ottens wrote:
So what do we do with that one?
Afaik Chusslove said drop, I have no clue tbh, haven't had time to invest on
i18n/kf5 and don't forsee i'll have much :/
- Albert
---
This is an
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117437/#review55246
---
This review has been submitted with commit
Hello,
On Tuesday 08 April 2014 19:51:05 Lamarque Souza wrote:
I understood that, I just do not know all the other things we need to do
to make NMQt/MMQt part of KF5. And yes, I agree in making NMQt/MMQt part of
KF5. The other doubt I still have is where _kde_add_platform_definitions
is
32 matches
Mail list logo
