On Wednesday 20 August 2014 11:38:12 Jonathan Riddell wrote:
> On Wed, Aug 20, 2014 at 12:28:30PM +0200, Aleix Pol wrote:
> >On Tue, Aug 19, 2014 at 9:49 PM, David Faure wrote:
> > On Tuesday 01 July 2014 22:25:15 Jonathan Riddell wrote:
> > > On Tue, Jul 01, 2014 at 11:25:11PM +0200
On 24 Aug 2014, at 23:54 , Aleix Pol wrote:
> On Sun, Aug 24, 2014 at 11:51 PM, Marko Käning wrote:
> On 24 Aug 2014, at 23:48 , Aleix Pol wrote:
> > Hm, fair enough. How does it sound to make kio-extras a framework then? It
> > doesn't add new API but it does add run-time functionality to the
On Sun, Aug 24, 2014 at 11:51 PM, Marko Käning wrote:
> On 24 Aug 2014, at 23:48 , Aleix Pol wrote:
> > Hm, fair enough. How does it sound to make kio-extras a framework then?
> It doesn't add new API but it does add run-time functionality to the
> applications.
>
> Oh, I thought kio-extras IS a
On 24 Aug 2014, at 23:48 , Aleix Pol wrote:
> Hm, fair enough. How does it sound to make kio-extras a framework then? It
> doesn't add new API but it does add run-time functionality to the
> applications.
Oh, I thought kio-extras IS a framework already…
_
On Wed, Aug 20, 2014 at 12:48 PM, Luigi Toscano
wrote:
> On Wednesday 20 of August 2014 11:38:12 Jonathan Riddell wrote:
> > On Wed, Aug 20, 2014 at 12:28:30PM +0200, Aleix Pol wrote:
> > >On Tue, Aug 19, 2014 at 9:49 PM, David Faure wrote:
> > > On Tuesday 01 July 2014 22:25:15 Jonatha
On Wednesday 20 of August 2014 11:38:12 Jonathan Riddell wrote:
> On Wed, Aug 20, 2014 at 12:28:30PM +0200, Aleix Pol wrote:
> >On Tue, Aug 19, 2014 at 9:49 PM, David Faure wrote:
> > On Tuesday 01 July 2014 22:25:15 Jonathan Riddell wrote:
> > > On Tue, Jul 01, 2014 at 11:25:11PM +0
On Wed, Aug 20, 2014 at 12:28:30PM +0200, Aleix Pol wrote:
>On Tue, Aug 19, 2014 at 9:49 PM, David Faure wrote:
>
> On Tuesday 01 July 2014 22:25:15 Jonathan Riddell wrote:
> > On Tue, Jul 01, 2014 at 11:25:11PM +0200, David Faure wrote:
> > > On Sunday 27 April 2014 19:35:37 I
On Tue, Aug 19, 2014 at 9:49 PM, David Faure wrote:
> On Tuesday 01 July 2014 22:25:15 Jonathan Riddell wrote:
> > On Tue, Jul 01, 2014 at 11:25:11PM +0200, David Faure wrote:
> > > On Sunday 27 April 2014 19:35:37 I wrote:
> > > > > * place that repo in kde/ or kde/ in the
> projects.kde.org
> >
On Tuesday 19 August 2014, David Faure wrote:
> > > Does anyone disagree with my line of thought above?
> >
> > plasma-devel list may also have an opinion on this, sending there.
>
> Any news?
To me it should be in whatever place it is better for most people, and if
there are use cases for it b
On Tuesday 01 July 2014 22:25:15 Jonathan Riddell wrote:
> On Tue, Jul 01, 2014 at 11:25:11PM +0200, David Faure wrote:
> > On Sunday 27 April 2014 19:35:37 I wrote:
> > > > * place that repo in kde/ or kde/ in the projects.kde.org
> > > > hierarchy, so that it gets released with the KDE Applicatio
On Tue, Jul 01, 2014 at 11:25:11PM +0200, David Faure wrote:
> On Sunday 27 April 2014 19:35:37 I wrote:
> > > * place that repo in kde/ or kde/ in the projects.kde.org
> > > hierarchy, so that it gets released with the KDE Applications, NOT with
> > > the
> > > workspace product. Support for kio_f
On Sunday 27 April 2014 19:35:37 I wrote:
> > * place that repo in kde/ or kde/ in the projects.kde.org
> > hierarchy, so that it gets released with the KDE Applications, NOT with
> > the
> > workspace product. Support for kio_fish/kio_sftp on Windows or Gnome
> > desktops is one of the major selli
On Sun, Apr 27, 2014 at 3:39 PM, David Faure wrote:
> On Tuesday 08 April 2014 06:02:33 Àlex Fiestas wrote:
> > 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
On Sunday 27 April 2014 15:39:05 David Faure wrote:
> On Tuesday 08 April 2014 06:02:33 Àlex Fiestas wrote:
> > 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
On Tuesday 08 April 2014 06:02:33 Àlex Fiestas wrote:
> 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, ot
On Thursday 10 April 2014 19:52:34 Àlex Fiestas wrote:
>
> So like I said in the sprint is it is something nice to have but it has to
> be maintained, fixed and polished and that won't happen before 2.0 and
> there is no reason to believe it will ever happen (since nobody at the
> sprint even knew
Hello,
On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote:
> > The problem is manpower, we do not have the manpwoer to maintain half o
> > the things we have in the workspace, most of the things in there are
> > half-cooked or they do not even work (kglobalaccel kcm)
For the record, it works
Am Freitag, 11. April 2014, 02:21:22 schrieb Aurélien Gâteau:
> On Fri, Apr 11, 2014, at 1:51, Àlex Fiestas wrote:
> > On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote:
> > > > The problem is manpower, we do not have the manpwoer to maintain half
> > > > o
> > > > the
> > > > things we have i
On Fri, Apr 11, 2014, at 1:51, Àlex Fiestas wrote:
> On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote:
> > > The problem is manpower, we do not have the manpwoer to maintain half o
> > > the
> > > things we have in the workspace, most of the things in there are
> > > half-cooked
> > > or they
On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote:
> > The problem is manpower, we do not have the manpwoer to maintain half o
> > the
> > things we have in the workspace, most of the things in there are
> > half-cooked
> > or they do not even work (kglobalaccel kcm) and instead of taking a
>
> The problem is manpower, we do not have the manpwoer to maintain half o
> the
> things we have in the workspace, most of the things in there are
> half-cooked
> or they do not even work (kglobalaccel kcm) and instead of taking a
> breath and
> decide what we want and what we do not want (like
On Thursday 10 April 2014 14:42:37 Marco Martin wrote:
> On Thursday 10 April 2014, you wrote:
> > in the second case, it's just a release blocker, and has to be enabled and
> > ported, *even if* there won't be anyone maintaining it after that, it's a
> > part of the workspace and needs to be relea
On Thursday 10 April 2014 13:43:37 Marco Martin wrote:
> On Thursday 10 April 2014, Àlex Fiestas wrote:
> > > Developers being confortable with it, or even (gasp!) being actively
> > > maintained goes completely secondary behind the causing as less
> > > regressions as possible for the users.
> >
On Thursday 10 April 2014, you wrote:
> in the second case, it's just a release blocker, and has to be enabled and
> ported, *even if* there won't be anyone maintaining it after that, it's a
> part of the workspace and needs to be released, (and yes, preferably in
> the plasma- workspace repo) if i
On Thursday 10 April 2014, Àlex Fiestas wrote:
> > Developers being confortable with it, or even (gasp!) being actively
> > maintained goes completely secondary behind the causing as less
> > regressions as possible for the users.
>
> I guess you can leave the code there and just not add it to cma
On Thursday 10 April 2014 10:40:04 Àlex Fiestas wrote:
> On Wednesday 09 April 2014 11:57:37 Marco Martin wrote:
> > On Wednesday 09 April 2014, Àlex Fiestas wrote:
> > > I'm against having anything in plasma-* without maintainer and even less
> > > if
> > > it is something that is known to have bu
On Wednesday 09 April 2014 11:57:37 Marco Martin wrote:
> On Wednesday 09 April 2014, Àlex Fiestas wrote:
> > I'm against having anything in plasma-* without maintainer and even less
> > if
> > it is something that is known to have bugs (many) in KDE4.
> >
> > So we wither split it and hope somebo
On Wednesday 09 April 2014 11:57:37 Marco Martin wrote:
> On Wednesday 09 April 2014, Àlex Fiestas wrote:
> > I'm against having anything in plasma-* without maintainer and even less
> > if
> > it is something that is known to have bugs (many) in KDE4.
> >
> > So we wither split it and hope somebo
On Wednesday 09 April 2014, Àlex Fiestas wrote:
> I'm against having anything in plasma-* without maintainer and even less if
> it is something that is known to have bugs (many) in KDE4.
>
> So we wither split it and hope somebody will give love to it or remove it.
Not talking about that repo in
On Tuesday 08 April 2014 17:37:00 Kevin Ottens wrote:
> Good move.
>
> Pushed me toward looking a bit closer to this page, as obviously we didn't
> look close enough before (sorry about that), I might have a concern still:
> solid-deviceautomounter getting its own repository. It looks again like a
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 obvious
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 hope
On Tue, Apr 8, 2014 at 1:55 PM, Alex Merry 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 me.
>
>
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 thos
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 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 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
___
Kde-framework
On Tue, Apr 8, 2014 at 12:27 AM, 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 Tue, Apr 8, 2014 at 12:55 PM, Kevin Ottens 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 re
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 7:57 AM, Kevin Ottens 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, etc)
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, etc) in kio, other useful ones (archive,
> bookmarks, etc) in "kioslave
On Mon, April 7, 2014 23:27:33 Alex Merry wrote:
> Moving things between repos is a *pain*, and I think Ben and Albert have
> a point about being over-eager to split things up. In this case, I
> think we should just have core things in kio, and everything else in
> kioslaves (or call it kio-extra-
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 curiosities (cgi, finger) in
kioslave-extra.
In my view, thi
44 matches
Mail list logo