On vendredi 20 mars 2020 12:16:09 CET David Edmundson wrote:
> >> > Kirigami seems to be rather unstable, I wonder if anything can be done
> >> > to
> >> > improve upon that [*].
> >>
> >> One important thing seems to have been getting sloppy in those repos;
> >> mandatory code reviews.
> >>
>> > Kirigami seems to be rather unstable, I wonder if anything can be done to
>> > improve upon that [*].
>
>> One important thing seems to have been getting sloppy in those repos;
>> mandatory code reviews.
>> That's an easy thing to enforce, and we know it makes a huge difference to
>> code.
>>
On 2/18/20 1:37 PM, Albert Astals Cid wrote:
I still don't see why this is a problem, as said Plasma depends on a myriad of
libraries that are building each with their own release model, most probably
with no bugfix releases at all either.
The "we don't control the whole stack" argument does
On 2/18/20 2:13 PM, Luca Beltrame wrote:
In data martedì 18 febbraio 2020 19:26:21 CET, Nate Graham ha scritto:
Neon is already an OS, whether or not you want to admit it. It's
installed from an ISO. A hardware vendor (Slimbook) is shipping it on
Erm, where did I say that in my reply? ;)
In data martedì 18 febbraio 2020 19:26:21 CET, Nate Graham ha scritto:
> Neon is already an OS, whether or not you want to admit it. It's
> installed from an ISO. A hardware vendor (Slimbook) is shipping it on
Erm, where did I say that in my reply? ;) I merely say that going "Neon or
else
El dimarts, 18 de febrer de 2020, a les 4:03:05 CET, Nate Graham va escriure:
> On 2020-02-16 14:43, Albert Astals Cid wrote:
> > Maybe i explain myself wrongly, i'm not blaming distros at all.
> >
> > They made a decision, we/I may agree with them or not, that's *my/our*
> > problem, what I was
> > IMHO distributions using Plasma LTS, Plasma team & other stakeholders should
> > team up here and maintain a matching LTS branch of Frameworks together at
> > the
> > central KDE repos together. Well, and a version also satisfying other
> > clients
> > of KF, like non-workspace applications
On 2/16/20 2:55 PM, Friedrich W. H. Kossebau wrote:
Yes, this has been questioned a few times. Also seeing Plasma LTS used
together with a non-LTS Qt is a bit strange.
But somehow it seems there has not been enough pain for those using the Plasma
LTS to change something. Possibly because
On 2/17/20 11:08 PM, Luca Beltrame wrote:
In data martedì 18 febbraio 2020 04:03:05 CET, Nate Graham ha scritto:
think KDE software should be presented to users. Basically, we
acknowledge that Neon is already an actual OS--the "KDE OS"--and we
Please don't suggest such downstream-hostile
On 2/16/20 2:55 PM, Friedrich W. H. Kossebau wrote:
Yes, this has been questioned a few times. Also seeing Plasma LTS used
together with a non-LTS Qt is a bit strange.
But somehow it seems there has not been enough pain for those using the Plasma
LTS to change something. Possibly because
Am Dienstag, 18. Februar 2020, 04:03:05 CET schrieb Nate Graham:
> On 2020-02-16 14:43, Albert Astals Cid wrote:
> > Maybe i explain myself wrongly, i'm not blaming distros at all.
> >
> > They made a decision, we/I may agree with them or not, that's *my/our*
> > problem, what I was disagreeing
In data martedì 18 febbraio 2020 04:03:05 CET, Nate Graham ha scritto:
> think KDE software should be presented to users. Basically, we
> acknowledge that Neon is already an actual OS--the "KDE OS"--and we
Please don't suggest such downstream-hostile solutions, in particular because
this
On 2020-02-16 14:43, Albert Astals Cid wrote:
Maybe i explain myself wrongly, i'm not blaming distros at all.
They made a decision, we/I may agree with them or not, that's *my/our* problem,
what I was disagreeing is to us having to do extra work because someone elses
(the distros) decision.
On Mon, Feb 17, 2020 at 10:55 AM Friedrich W. H. Kossebau
wrote:
>
> Sorry, no time to rewrite to make this short.
>
> Am Mittwoch, 12. Februar 2020, 21:59:32 CET schrieb Nate Graham:
> > [+ frameworks and plasma mailing lists]
> >
> > On 2020-02-12 11:31, Albert Astals Cid wrote:
> > > El
On Mon, Feb 17, 2020 at 10:43 AM Albert Astals Cid wrote:
>
> El diumenge, 16 de febrer de 2020, a les 22:34:51 CET, David Faure va
> escriure:
> > On dimanche 16 février 2020 22:17:17 CET Albert Astals Cid wrote:
> > > This is their fault, they as a distribution have decided to support a
> > >
Sorry, no time to rewrite to make this short.
Am Mittwoch, 12. Februar 2020, 21:59:32 CET schrieb Nate Graham:
> [+ frameworks and plasma mailing lists]
>
> On 2020-02-12 11:31, Albert Astals Cid wrote:
> > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va
escriure:
> >> On
El diumenge, 16 de febrer de 2020, a les 22:34:51 CET, David Faure va escriure:
> On dimanche 16 février 2020 22:17:17 CET Albert Astals Cid wrote:
> > This is their fault, they as a distribution have decided to support a random
> > KDE Frameworks version for longer than we do support it, so they
On dimanche 16 février 2020 22:17:17 CET Albert Astals Cid wrote:
> This is their fault, they as a distribution have decided to support a random
> KDE Frameworks version for longer than we do support it, so they are the
> ones that should be the job of supporting it.
>
> It's like you are trying
El dissabte, 15 de febrer de 2020, a les 20:35:23 CET, Nate Graham va escriure:
> On 2020-02-15 11:55, Ben Cooksley wrote:
> > My point above was that the version you decide to freeze on should
> > only be the version you depend on during development.
> > The version you depend on when you release
On Sun, Feb 16, 2020 at 8:35 AM Nate Graham wrote:
>
> On 2020-02-15 11:55, Ben Cooksley wrote:
> > My point above was that the version you decide to freeze on should
> > only be the version you depend on during development.
> > The version you depend on when you release will be the next release
On 2020-02-15 11:55, Ben Cooksley wrote:
My point above was that the version you decide to freeze on should
only be the version you depend on during development.
The version you depend on when you release will be the next release of
Frameworks (so by freezing on 5.66 for development, it should
On Sat, Feb 15, 2020 at 8:10 AM Nate Graham wrote:
>
> On 2020-02-13 00:42, Ben Cooksley wrote:
> > A better way of approaching this would be to freeze the Frameworks
> > version you are going to require API wise at an earlier point in the
> > Plasma development cycle. This would allow for a full
On 2020-02-13 00:42, Ben Cooksley wrote:
A better way of approaching this would be to freeze the Frameworks
version you are going to require API wise at an earlier point in the
Plasma development cycle. This would allow for a full Frameworks
release cycle to pass where bugs encountered during
On jeudi 13 février 2020 09:46:20 CET David Edmundson wrote:
> > Kirigami seems to be rather unstable, I wonder if anything can be done to
> > improve upon that [*].
>
> One important thing seems to have been getting sloppy in those repos;
> mandatory code reviews.
> That's an easy thing to
> Kirigami seems to be rather unstable, I wonder if anything can be done to
> improve upon that [*].
>
One important thing seems to have been getting sloppy in those repos;
mandatory code reviews.
That's an easy thing to enforce, and we know it makes a huge difference to code.
Even if no-one
On Thu, Feb 13, 2020 at 9:00 PM Christoph Feck wrote:
>
> On 02/13/20 08:42, Ben Cooksley wrote:
> > Part of the issue here is that Plasma has been known to add API to
> > Frameworks and then immediately, without any delay, start using it
> > (pretty much always breaking CI in the process)
> >
>
On 02/13/20 08:42, Ben Cooksley wrote:
Part of the issue here is that Plasma has been known to add API to
Frameworks and then immediately, without any delay, start using it
(pretty much always breaking CI in the process)
This means that other changes are likely being pushed into Frameworks
by
On Thu, Feb 13, 2020 at 10:00 AM Nate Graham wrote:
>
> [+ frameworks and plasma mailing lists]
>
>
> On 2020-02-12 11:31, Albert Astals Cid wrote:
> > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va
> > escriure:
> >> Personally I think it would be nice to have
> >>
Hello,
Since I'm not on release-team I'm discovering this just now.
On Wednesday, 12 February 2020 21:59:32 CET Nate Graham wrote:
> [+ frameworks and plasma mailing lists]
>
> On 2020-02-12 11:31, Albert Astals Cid wrote:
> > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham
[+ frameworks and plasma mailing lists]
On 2020-02-12 11:31, Albert Astals Cid wrote:
El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va escriure:
Personally I think it would be nice to have
86f988434cd657e77cc9429e78f7290ce6b5713d since otherwise LTS Plasma
users will be
El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va escriure:
> Personally I think it would be nice to have
> 86f988434cd657e77cc9429e78f7290ce6b5713d since otherwise LTS Plasma
> users will be hitting it for the next few years.
>
> ---
>
> On another note, I have to admit
Personally I think it would be nice to have
86f988434cd657e77cc9429e78f7290ce6b5713d since otherwise LTS Plasma
users will be hitting it for the next few years.
---
On another note, I have to admit I'm starting to doubt how well our LTS
Plasma product works without a corresponding LTS
On Wed, Feb 12, 2020 at 12:56 PM David Faure wrote:
>
> On mercredi 12 février 2020 12:48:48 CET you wrote:
> > Hi David,
> > me again, sorry :/
> > there seem to have been 2 regressions in kirigami 5.67 which are
> > affecting the lts release of plasma in a quite user visible way
> >
> > fixes
On mercredi 12 février 2020 12:48:48 CET you wrote:
> Hi David,
> me again, sorry :/
> there seem to have been 2 regressions in kirigami 5.67 which are
> affecting the lts release of plasma in a quite user visible way
>
> fixes for them are
> 86f988434cd657e77cc9429e78f7290ce6b5713d
> and
>
34 matches
Mail list logo
