Fwd: KCalendarCore Require Libcal 3.0

[Allen Winter]

I plan to implement this new requirement 2 weeks from now.
unless there are good reasons against.

-Allen

--  Forwarded Message  --

Subject: KCalendarCore Require Libcal 3.0
Date: Tuesday, November 17, 2020, 12:10:22 PM EST
From: Allen Winter 
To: KDE release coordination 

Release Team,

Unless there are objections, I'd like to require libical v3.0 in kcalendarcore.
libical v3.0.0 was released over 3 years ago (28 Oct 2017)






-

Re: Synchronized release schedule for Plasma

[David Edmundson]

>
> As distribution package maintainers, we would like Plasma developers to
> slightly alter the release schedule to align releases with a more
> distribution friendly cycle. You could consider shortening one release
> cycle (and then keep the 6 month schedule) to align releases.
>

We have in the past shuffled things slightly to line up things up with
distros on request, particularly LTS releases. We can certainly explore
that on a one-off basis.

>With this schedule in place, we would also benefit from more beta releases
over a slightly longer period. They would be packaged into the beta and RC
releases of those distributions thus enabling more pre-release testing.

We did have 6 month release cycles in the past.

The rationale for moving at the time was twofold:
 - people rushed in changes towards the feature freeze as otherwise it
would be aages till their changes reached users
 - the more changes we have in a release, the more testing and inevitable
regression fixes we need to do, spreading that out should result in things
being more stable

Initially we did every 3 months (which arguably still aligns) then it
slowly slipped to 4.

My personal impression is that releases have gotten better as a result of
those changes, so I'm hesitant about reverting that decision.

David


>

Synchronized release schedule for Plasma

[Timothée Ravier]

Hi KDE/Plasma developers!

Nowadays, Fedora and Kubuntu make new releases twice a year within a week
of each other, with relatively predictable release schedules.

Unfortunately, new KDE/Plasma releases happen a little bit too late for
them to be included in those distributions in time for the release. Thus
the current version of KDE/Plamsa in both Fedora and Kubuntu is one release
behind (at least on release day). It may or may not be updated after the
release.

For the Fedora KDE SIG, we have an issue about this:
https://pagure.io/fedora-kde/SIG/issue/25

As distribution package maintainers, we would like Plasma developers to
slightly alter the release schedule to align releases with a more
distribution friendly cycle. You could consider shortening one release
cycle (and then keep the 6 month schedule) to align releases.

With this schedule in place, we would also benefit from more beta releases
over a slightly longer period. They would be packaged into the beta and RC
releases of those distributions thus enabling more pre-release testing.

All of this would benefit both upstream and downstream:

  - More pre-release and just released software testing as users test the
new distribution version directly with the KDE beta and fresh stable
releases
  - More updated and happy users using the latest release
  - Less bugs reported against older releases, more bugs reported before
the final stable releases

What do you think?

Thanks!

Timothée Ravier for the Fedora KDE SIG

-- 

Timothée Ravier

Red Hat & Fedora CoreOS Engineer

Red Hat 

trav...@redhat.comIM: travier

Re: Synchronized release schedule for Plasma

[Niccolò Ve]

Hi,
Currently there is a KDE Plasma every 4 months. You are suggesting to
change that to 6 months, is that correct?
Niccolò

2020-11-24 16:07 (GMT+01:00), "Timothée Ravier"  said:
> Hi KDE/Plasma developers!
> Nowadays, Fedora and Kubuntu make new releases twice a year within a week of
> each other, with relatively predictable release schedules.
> Unfortunately, new KDE/Plasma releases happen a little bit too late for them 
> to
> be included in those distributions in time for the release. Thus the current
> version of KDE/Plamsa in both Fedora and Kubuntu is one release behind (at
> least on release day). It may or may not be updated after the release.
> For the Fedora KDE SIG, we have an issue about this:
> https://pagure.io/fedora-kde/SIG/issue/25
> As distribution package maintainers, we would like Plasma developers to
> slightly alter the release schedule to align releases with a more distribution
> friendly cycle. You could consider shortening one release cycle (and then keep
> the 6 month schedule) to align releases.
> With this schedule in place, we would also benefit from more beta releases 
> over
> a slightly longer period. They would be packaged into the beta and RC releases
> of those distributions thus enabling more pre-release testing.
> All of this would benefit both upstream and downstream:
> - More pre-release and just released software testing as users test the new
> distribution version directly with the KDE beta and fresh stable releases
> - More updated and happy users using the latest release
> - Less bugs reported against older releases, more bugs reported before the
> final stable releases
> What do you think?
> Thanks!
> Timothée Ravier for the Fedora KDE SIG
> --
> Timothée Ravier
> Red Hat & Fedora CoreOS Engineer
> https://www.redhat.com/";>Red Hat
> trav...@redhat.com IM: travier
>

[ANNOUNCE] CMake 3.19.1 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.19.1 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.19.1 since 3.19.0:

Brad King (10):
  ci: update to use CMake 3.19.0
  gitlab-ci: update macOS jobs to use Xcode 12.0
  Revert "specify language flag when source LANGUAGE property is set"
  FindGTest: Revert "Allow either "Debug" or "Release" configurations."
  Makefiles: Fix CMAKE_EXPORT_COMPILE_COMMANDS crash with custom compile
rule
  Xcode: Fix custom command work-dir placeholders in "new build system"
  Tests: Match RunCMake.CMP0111 stderr more strictly
  cmTarget: Do not enforce CMP0111 on imported INTERFACE libraries
  cmVisualStudio10TargetGenerator: Avoid GetFullPath on INTERFACE library
  CMake 3.19.1

Kyle Edwards (1):
  cmGlobalGenerator: FindMakeProgram() at a generator-specific time

Marc Chevrier (1):
  cmFileTime: Fix overflow on time computation

Nikita Nemkin (1):
  Help: Fix `.. versionadded` directives for CTEST_CUSTOM_* variables

Raul Tambre (2):
  CUDA: Clang CUDA 11.1 support
  CUDA: Error if can't determine toolkit library root

Re: Fwd: KCalendarCore Require Libical 3.0

[Allen Winter]

Sorry. typo in the original message subject.
This is about "Libical" not "Libcal"

On Tuesday, November 24, 2020 8:13:12 AM EST Allen Winter wrote:
> I plan to implement this new requirement 2 weeks from now.
> unless there are good reasons against.
> 
> -Allen
> 
> --  Forwarded Message  --
> 
> Subject: KCalendarCore Require Libcal 3.0
> Date: Tuesday, November 17, 2020, 12:10:22 PM EST
> From: Allen Winter 
> To: KDE release coordination 
> 
> Release Team,
> 
> Unless there are objections, I'd like to require libical v3.0 in 
> kcalendarcore.
> libical v3.0.0 was released over 3 years ago (28 Oct 2017)
> 
> 
> 
> 
> 
> 
> -
> 
> 
> 

Licensing - KGet

[Justin Zobel]

Hey Team,

Been doing bug triage on bugs.kde.org and I came across this one. I'm
not going to touch it as licensing is a delicate subject.

Can someone familiar with or working on the kget team please action
this ticket, thanks.

https://bugs.kde.org/show_bug.cgi?id=330881

Regards,

Justin

Re: Fwd: KCalendarCore Require Libical 3.0

[Adriaan de Groot]

On Tuesday, 24 November 2020 22:39:44 CET Allen Winter wrote:
> On Tuesday, November 24, 2020 8:13:12 AM EST Allen Winter wrote:
> > I plan to implement this new requirement 2 weeks from now.
> > unless there are good reasons against.
> > 
> > Unless there are objections, I'd like to require libical v3.0 in
> > kcalendarcore. libical v3.0.0 was released over 3 years ago (28 Oct 2017)

That's fine from the KDE-FreeBSD side, CI builders are up-to-date:

libical-3.0.8_1Implementation of the IETF Calendaring and 
Scheduling protocols

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Licensing - KGet

[Nicolás Alvarez]

El mar, 24 de nov. de 2020 a la(s) 19:37, Justin Zobel
(justin.zo...@gmail.com) escribió:
>
> Hey Team,
>
> Been doing bug triage on bugs.kde.org and I came across this one. I'm
> not going to touch it as licensing is a delicate subject.
>
> Can someone familiar with or working on the kget team please action
> this ticket, thanks.
>
> https://bugs.kde.org/show_bug.cgi?id=330881

I see you marked that as a duplicate of 322396, so I have posted my
non-legal-but-maybe-correct understanding there.

-- 
Nicolás

Archiving all Qt4 apps

[Nicolas Fella]

Hi,

while going over our repos on invent I found a few (non-archived) repos
where the master branch is still Qt4-based. Given that Qt6 is just
around the corner this is a clear sign that they are
unmaintained/abandoned. I therefore propose to move them to unmaintained
and do everything that implies.

The projects in question are:

knipptasch
kdisksutilities
abakus
akonadi-exchange
kte-collaborative
kwooty
kio-upnp-ms
kscd


Cheers

Nico

Re: Archiving all Qt4 apps

[Nate Graham]

+1

Nate


On 11/24/20 5:11 PM, Nicolas Fella wrote:

Hi,

while going over our repos on invent I found a few (non-archived) repos
where the master branch is still Qt4-based. Given that Qt6 is just
around the corner this is a clear sign that they are
unmaintained/abandoned. I therefore propose to move them to unmaintained
and do everything that implies.

The projects in question are:

knipptasch
kdisksutilities
abakus
akonadi-exchange
kte-collaborative
kwooty
kio-upnp-ms
kscd


Cheers

Nico