On Jun 16, 2015 12:14 PM, Christian Mollekopf chrig...@fastmail.fm
wrote:
I'm glad to hear that. Until then I guess my options are limited:
* I can keep kimap out of frameworks, but that doesn't buy me a whole
lot as I still rely on other frameworks,
and most of the PIM libraries really ought
2015-06-16 12:54 GMT+03:00 Christian Mollekopf chrig...@fastmail.fm:
On Sun, Jun 14, 2015, at 07:53 PM, Alexander Potashev wrote:
2015-06-11 21:20 GMT+03:00 Sebastian Kügler se...@kde.org:
Introducing exceptions increases the complexity of dealing with frameworks,
their value really is in
On Tuesday, June 16, 2015 11:45:06 Christian Mollekopf wrote:
Let's not forget that we're talking about a few hundred deployers here,
and
perhaps a lot more we don't know about, and then hopefully a whole lot
more in
the future. The consistency across frameworks at this basic project
On Tuesday, June 16, 2015 11:45:06 Christian Mollekopf wrote:
On Thu, Jun 11, 2015, at 08:56 PM, Sebastian Kügler wrote:
On Tuesday, June 09, 2015 10:08:06 Christian Mollekopf wrote:
I'm sorry for the friction this causes right now, but in the long run I
really don't see how this makes
2015-06-11 21:20 GMT+03:00 Sebastian Kügler se...@kde.org:
Introducing exceptions increases the complexity of dealing with frameworks,
their value really is in shared processes and requirements.
I am strongly against watering it down. If some library is better off with its
own versioning
On Tuesday, June 09, 2015 10:08:06 Christian Mollekopf wrote:
I'm sorry for the friction this causes right now, but in the long run I
really don't see how this makes life harder for everyone else.
Here's an example from some recent packaging experiments. I wrote a script to
update the
On Tuesday 09 June 2015 16:58:43 Christian Mollekopf wrote:
On Tuesday 09 June 2015 15:35:20 Heinz Wiesinger wrote:
Do note that while a typical linux distribution does ship with an
abundance
of libraries that need to be handled differently, very seldomly those are
maintained by the
On Monday 08 June 2015 18:07:48 laurent Montel wrote:
Le Monday 08 June 2015 01:28:04 David Faure a écrit :
Hello packagers,
The thread Versioning of Frameworks on kde-frameworks-devel has led to
the idea that some future frameworks (coming from the kdepim world) would
not be part of
On Tuesday 09 June 2015 10:28:48 Christian Mollekopf wrote:
On Monday 08 June 2015 10:07:40 Maximiliano Curia wrote:
On 08/06/15 01:28, David Faure wrote:
The thread Versioning of Frameworks on kde-frameworks-devel has led to
the idea that some future frameworks (coming from the kdepim
On Monday 08 June 2015 11:21:56 Benjamin Reed wrote:
On 6/8/15 11:02 AM, Eric Hameleers wrote:
The only sane way forward is that every Frameworks release contains
all Frameworks tarballs, regardless of updates since the previous
public release. Every Framework should adhere to the overall
On Monday 08 June 2015 18:38:11 Hrvoje Senjan wrote:
2015-06-08 1:28 GMT+02:00 David Faure fa...@kde.org:
Hello packagers,
The thread Versioning of Frameworks on kde-frameworks-devel has led to
the idea that some future frameworks (coming from the kdepim world) would
not be part of
On Monday 08 June 2015 18:47:06 Kevin Ottens wrote:
Hello,
Hey,
On Monday 08 June 2015 01:28:04 David Faure wrote:
The thread Versioning of Frameworks on kde-frameworks-devel has led to
the idea that some future frameworks (coming from the kdepim world) would
not be part of every
On Monday 08 June 2015 10:07:40 Maximiliano Curia wrote:
On 08/06/15 01:28, David Faure wrote:
The thread Versioning of Frameworks on kde-frameworks-devel has led to
the idea that some future frameworks (coming from the kdepim world) would
not be part of every Frameworks release, and would
On Tuesday 09 June 2015 01:02:52 Pau Garcia i Quiles wrote:
Hello,
Boost is essentially equivalent to KF5:
- lots of libraries
- some depend on others, some don't
- some libraries get updated almost every release, others are hardly
updated
Boost includes all libraries
On Monday 08 June 2015 10:07:40 Maximiliano Curia wrote:
Since you ask about it, the tool used in Debian to fetch upstream releases
(uscan and watch files) expects to be able to fetch a list of files with a
single request (something like https://pypi.python.org/simple/isodate/), so
it better
2015-06-09 16:58 GMT+02:00 Christian Mollekopf chrig...@fastmail.fm:
...
Yes, it's a bit more complex, but it's necessary/useful complexity (because
you gain something from it). It's however still perfectly scriptable.
Can you explain why is it necessary and useful and what do we
(packagers, or
On 6/8/15 4:29 PM, Mario Fux wrote:
Either I don't get this sarcasm or you might be wrong.
Yeah, sorry, I did an incredibly horrible job of describing what I meant.
The whole point of KDE Frameworks is that it is _modular_ and not
monolithic
as kdelibs was. As I see it the value of KDE
On Tuesday 09 June 2015 17:43:28 Hrvoje Senjan wrote:
2015-06-09 16:58 GMT+02:00 Christian Mollekopf chrig...@fastmail.fm:
...
Yes, it's a bit more complex, but it's necessary/useful complexity
(because
you gain something from it). It's however still perfectly scriptable.
Can you
Hello,
On Tuesday 09 June 2015 10:08:06 Christian Mollekopf wrote:
On Monday 08 June 2015 18:47:06 Kevin Ottens wrote:
Is it me or this whole thing is making most people life harder to please
one person? I'm getting this feeling based on the past discussions on
k-f-d and the replies here.
On Monday, June 08, 2015 10:48:42 AM Rex Dieter wrote:
David Faure wrote:
Hello packagers,
The thread Versioning of Frameworks on kde-frameworks-devel has led to
the idea that some future frameworks (coming from the kdepim world) would
not be part of every Frameworks release, and would
On Tuesday 09 June 2015 11:49:55 Christian Mollekopf wrote:
On Tuesday 09 June 2015 11:16:17 Raymond Wooninck wrote:
On Tuesday 09 June 2015 10:50:36 Christian Mollekopf wrote:
So all in all, we as packagers trying to utilize whatever we can to ensure
that our users are ending up with a
Am Montag, 08. Juni 2015, 17.21:56 schrieb Benjamin Reed:
Morning
On 6/8/15 11:02 AM, Eric Hameleers wrote:
The only sane way forward is that every Frameworks release contains
all Frameworks tarballs, regardless of updates since the previous
public release. Every Framework should adhere
On Mon, June 8, 2015 22:29:16 Mario Fux wrote:
Am Montag, 08. Juni 2015, 17.21:56 schrieb Benjamin Reed:
Morning
On 6/8/15 11:02 AM, Eric Hameleers wrote:
The only sane way forward is that every Frameworks release contains
all Frameworks tarballs, regardless of updates since the
David Faure wrote:
Would that work for you guys?
I can see this becoming a packaging nightmare quickly if other packages
follow suit. Our packaging is currently mostly automated: just bump the
version number and packages are built and pushed automatically. With this
change we would need to
On Sun, Jun 7, 2015 at 4:28 PM, David Faure fa...@kde.org wrote:
Hello packagers,
The thread Versioning of Frameworks on kde-frameworks-devel has led to the
idea that some future frameworks (coming from the kdepim world) would not be
part of every Frameworks release, and would have their own
On 08/06/15 01:28, David Faure wrote:
The thread Versioning of Frameworks on kde-frameworks-devel has led to the
idea that some future frameworks (coming from the kdepim world) would not be
part of every Frameworks release, and would have their own versioning scheme.
This is at the request
On 08/06/15 09:28, David Faure wrote:
Hello packagers,
The thread Versioning of Frameworks on kde-frameworks-devel has led to the
idea that some future frameworks (coming from the kdepim world) would not be
part of every Frameworks release, and would have their own versioning scheme.
This
On Tue, 9 Jun 2015, Michael Palimaka wrote:
Date: Tue, 09 Jun 2015 00:25:24 +1000
From: Michael Palimaka kensing...@gentoo.org
Reply-To: KDE release coordination release-team@kde.org
To: release-team@kde.org
Subject: Re: Future frameworks releases
On 08/06/15 09:28, David Faure wrote:
Hello
On 6/8/15 11:02 AM, Eric Hameleers wrote:
The only sane way forward is that every Frameworks release contains
all Frameworks tarballs, regardless of updates since the previous
public release. Every Framework should adhere to the overall version
number.
Yeah, this proposal makes no sense to
David Faure wrote:
Hello packagers,
The thread Versioning of Frameworks on kde-frameworks-devel has led to
the idea that some future frameworks (coming from the kdepim world) would
not be part of every Frameworks release, and would have their own
versioning scheme. This is at the request
2015-06-08 1:28 GMT+02:00 David Faure fa...@kde.org:
Hello packagers,
The thread Versioning of Frameworks on kde-frameworks-devel has led to the
idea that some future frameworks (coming from the kdepim world) would not be
part of every Frameworks release, and would have their own versioning
Hello,
On Monday 08 June 2015 01:28:04 David Faure wrote:
The thread Versioning of Frameworks on kde-frameworks-devel has led to the
idea that some future frameworks (coming from the kdepim world) would not
be part of every Frameworks release, and would have their own versioning
scheme. This
Le Monday 08 June 2015 01:28:04 David Faure a écrit :
Hello packagers,
The thread Versioning of Frameworks on kde-frameworks-devel has led to the
idea that some future frameworks (coming from the kdepim world) would not
be part of every Frameworks release, and would have their own versioning
Hello packagers,
The thread Versioning of Frameworks on kde-frameworks-devel has led to the
idea that some future frameworks (coming from the kdepim world) would not be
part of every Frameworks release, and would have their own versioning scheme.
This is at the request of their maintainer,
34 matches
Mail list logo
