Hello,
On Thursday 25 June 2015 16:02:44 Christian Mollekopf wrote:
> On Wednesday 17 June 2015 23.01:41 Kevin Ottens wrote:
> > On Tuesday 16 June 2015 11:14:28 Christian Mollekopf wrote:
> > I don't think you've been disrespectful. I guess that was the limit of my
> > metaphor which carried this
On Wednesday 17 June 2015 23.01:41 Kevin Ottens wrote:
> Hello,
>
Hey,
> On Tuesday 16 June 2015 11:14:28 Christian Mollekopf wrote:
> > On Tue, Jun 9, 2015, at 10:32 PM, Kevin Ottens wrote:
> > Sorry for the late response.
>
> No worries, it's not like I'm very responsive either. I didn't mana
El Diumenge, 14 de juny de 2015, a les 20:53:51, Alexander Potashev va
escriure:
> 2015-06-11 21:20 GMT+03:00 Sebastian Kügler :
> > Introducing exceptions increases the complexity of dealing with
> > frameworks,
> > their value really is in shared processes and requirements.
> >
> > I am strongl
Hello,
On Thursday 18 June 2015 09:29:12 Cornelius Schumacher wrote:
> My feeling is that we are approaching the end of what is possible to
> productively discuss via email. Maybe we should plan a session at Akademy to
> have a face-to-face discussion. If this is prepared a bit, it might be the
>
On Thursday 18 June 2015 01:03:42 Alexander Potashev wrote:
> Probing question: If I translate one string in kcoreaddons5_qt.po into
> Belarusian language, should we bump and release a new version of
> KCoreAddons because of that?
The question doesn't exactly make sense beceause the po files actua
On Thursday 18 June 2015 00:19:47 Sebastian Kügler wrote:
>
> I've seen so much energy wasted in KDE for a lack of clear decision-making
> process, and we have been through multiple iterations of trying to fix it
> (the Technical Working Group, for example), and we haven't found a better
> model.
On Wednesday, June 17, 2015 21:39:47 Kevin Ottens wrote:
> On Wednesday 17 June 2015 05:19:57 Sebastian Kügler wrote:
> > Maybe you should just trust the amount of negative reactions (and the fact
> > that they come from /all the right people/ and forget about your proposal.
> > Trust the elders.
>
2015-06-18 2:15 GMT+03:00 Aleix Pol :
> On Thu, Jun 18, 2015 at 12:03 AM, Alexander Potashev
> wrote:
>> 2015-06-18 0:01 GMT+03:00 Kevin Ottens :
>>> Bear with me I'll be partly acting from memory here... let's see something
>>> like:
>>> 1) KF5 releases are numbered .MM;
>>> 2) Individual f
On Thu, Jun 18, 2015 at 12:03 AM, Alexander Potashev
wrote:
> 2015-06-18 0:01 GMT+03:00 Kevin Ottens :
>> Bear with me I'll be partly acting from memory here... let's see something
>> like:
>> 1) KF5 releases are numbered .MM;
>> 2) Individual frameworks are numbered 5.N, N being incremented
2015-06-18 0:01 GMT+03:00 Kevin Ottens :
> Bear with me I'll be partly acting from memory here... let's see something
> like:
> 1) KF5 releases are numbered .MM;
> 2) Individual frameworks are numbered 5.N, N being incremented only if
> there's been commits since the last KF5 release;
>
> [*]
Hello,
On Tuesday 16 June 2015 11:14:28 Christian Mollekopf wrote:
> On Tue, Jun 9, 2015, at 10:32 PM, Kevin Ottens wrote:
> Sorry for the late response.
No worries, it's not like I'm very responsive either. I didn't manage to
participate properly on the k-f-d discussion on that topic for a star
Hello,
On Wednesday 17 June 2015 05:19:57 Sebastian Kügler wrote:
> Maybe you should just trust the amount of negative reactions (and the fact
> that they come from /all the right people/ and forget about your proposal.
> Trust the elders.
Seeing this argument being used by you, of all people, ho
On Jun 16, 2015 12:14 PM, "Christian Mollekopf"
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 to be framework
2015-06-16 12:54 GMT+03:00 Christian Mollekopf :
> On Sun, Jun 14, 2015, at 07:53 PM, Alexander Potashev wrote:
>> 2015-06-11 21:20 GMT+03:00 Sebastian Kügler :
>> > Introducing exceptions increases the complexity of dealing with frameworks,
>> > their value really is in shared processes and requir
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
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
On Tuesday 16 June 2015 21:43:56 Christian Mollekopf wrote:
>
> I think as part of each frameworks release, we could publish a similar
> manifest,
> i.e. http://download.kde.org/stable/frameworks/#{version_dir}/manifest,
> where version_dir is the frameworks release number.
> The manifest could be
On Tue, Jun 16, 2015, at 05:12 PM, Cornelius Schumacher wrote:
> On Tuesday 16 June 2015 11:25:07 Christian Mollekopf wrote:
> > On Wed, Jun 10, 2015, at 11:56 AM, Cornelius Schumacher wrote:
> > >
> > > For example for Inqlude I currently have a tool, which updates the meta
> > > data
> > > of
On Tuesday 16 June 2015 11:25:07 Christian Mollekopf wrote:
> On Wed, Jun 10, 2015, at 11:56 AM, Cornelius Schumacher wrote:
> >
> > For example for Inqlude I currently have a tool, which updates the meta
> > data
> > of all frameworks with each release. It only works because it can assume
> > tha
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 life harder for everyone else.
>
> Here's an example from some
On Thu, Jun 11, 2015, at 08:20 PM, Sebastian Kügler wrote:
> On Tuesday, June 09, 2015 10:39:58 Christian Mollekopf wrote:
> > 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 co
On Wed, Jun 10, 2015, at 11:56 AM, Cornelius Schumacher wrote:
> 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
On Tue, Jun 9, 2015, at 10:32 PM, Kevin Ottens wrote:
> Hello,
>
Hey Kevin,
Sorry for the late response.
> 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
2015-06-11 21:20 GMT+03:00 Sebastian Kügler :
> 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 scheme and re
On 09/06/15 09:35, David Faure wrote:
> 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
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 packag
On Tuesday, June 09, 2015 10:39:58 Christian Mollekopf wrote:
> 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
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 packag
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 b
On Tuesday 09 June 2015 10:01:40 Maximiliano Curia wrote:
> On 09/06/15 09:35, David Faure wrote:
> > 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 fetc
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
2015-06-09 18:31 GMT+02:00 Christian Mollekopf :
> On Tuesday 09 June 2015 17:43:28 Hrvoje Senjan wrote:
>> 2015-06-09 16:58 GMT+02:00 Christian Mollekopf :
>> ...
>>
>> > Yes, it's a bit more complex, but it's necessary/useful complexity
>> > (because
>> > you gain something from it). It's however
On Tuesday 09 June 2015 17:43:28 Hrvoje Senjan wrote:
> 2015-06-09 16:58 GMT+02:00 Christian Mollekopf :
> ...
>
> > 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
2015-06-09 16:58 GMT+02:00 Christian Mollekopf :
...
> 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 users) gain from i
On Tuesday 09 June 2015 15:35:20 Heinz Wiesinger wrote:
> 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
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 KD
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
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 releas
On Monday 08 June 2015 18:37:39 Michael Pyne wrote:
> (and especially,
> with a "stable" branch as proposed for KImap here)
No, this is not what is being proposed.
kimap (and some others) would also be released from master,
just not with the same version number and not everytime (*).
(see the thr
On Tue, Jun 9, 2015 at 10:53 PM, Pau Garcia i Quiles
wrote:
>
>
> On Tue, Jun 9, 2015 at 10:35 AM, Christian Mollekopf
> wrote:
>>
>> 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 wro
On Tue, Jun 9, 2015 at 10:35 AM, Christian Mollekopf
wrote:
> 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
On Tuesday 09 June 2015 11:16:17 Raymond Wooninck wrote:
> On Tuesday 09 June 2015 10:50:36 Christian Mollekopf wrote:
> > > Biggest problem here, at least for now as i can see, are dependency
> > > versions for those with their own scheme.
> > > Now we can have
> > > (build)requires >= %version
>
On Tuesday 09 June 2015 10:50:36 Christian Mollekopf wrote:
> > Biggest problem here, at least for now as i can see, are dependency
> > versions for those with their own scheme.
> > Now we can have
> > (build)requires >= %version
> > but with the new setup we would need to check each individual
> >
On Monday 08 June 2015 18:38:11 Hrvoje Senjan wrote:
> 2015-06-08 1:28 GMT+02:00 David Faure :
> > 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 ever
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 ove
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
On Monday 08 June 2015 18:49:07 Antonio Rojas wrote:
> 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
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, an
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
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 libra
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 e
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 bette
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 (except if they are retired entirely) and bump
version for all libraries at
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 sin
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 ad
On Sun, Jun 7, 2015 at 4:28 PM, 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 version
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 t
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.
2015-06-08 1:28 GMT+02:00 David Faure :
> 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.
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 vers
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 re
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 t
On Tue, 9 Jun 2015, Michael Palimaka wrote:
Date: Tue, 09 Jun 2015 00:25:24 +1000
From: Michael Palimaka
Reply-To: KDE release coordination
To: release-team@kde.org
Subject: Re: Future frameworks releases
On 08/06/15 09:28, David Faure wrote:
Hello packagers,
The thread "Versioni
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.
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 requ
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, Chr
66 matches
Mail list logo
