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
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/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
> > 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 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.
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 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
> > >
On Mon, Feb 17, 2020 at 4:42 AM David Edmundson
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
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 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
> 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 have had
> a release-day dependency
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 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:48, Kai Uwe Broulik wrote:
To minimize potential Frameworks dependency problems I would even go as
far as put Feature freeze on same date as Frameworks tagging date so
that no new stuff goes in that could require a Framework change, like
the wallpaper JPG vs PNG situation.
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
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
Hi,
> We have to ask: what causes buggy releases?
People rushing things in at the last minute, even better if unreviewed.
Plasma 5.18 was a prime example of this. Every single time there's drama
on Beta tagging day for some last minute change that should go in. To
remedy this I wanted Beta
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
33 matches
Mail list logo
