Re: Move Licentia to KDEREVIEW

[David Redondo]

Am Freitag, 8. Juli 2022, 07:36:57 CEST schrieb Felipe Kinoshita:
> Hey, I'd like to move Licentia  to
> KDEREVIEW.
> 
> Licentia is a simple app targeted at developers/creators who need to decide
> which license is suited to their projects, Licentia helps with that by
> listing a bunch of licenses, which with it's permissions, conditions and
> limitations, instructions about how to add a license to your project and a
> list of known projects that use said license.
> 
> Thanks,
> Felipe.

I am not entirely happy about the Instruction to use a license being 'put a 
LICENSE file in the root directory' when it's a pattern we are going away from 
and towards reuse compliance. 
Maybe display the SPDX tag instead?

David

Re: Move Licentia to KDEREVIEW

[David Redondo]

Am Montag, 11. Juli 2022, 12:37:09 CEST schrieben Sie:
>
> Please note that Gitlab and other places still do rely on LICENSE (or
> COPYING) files being present (and I guarantee there is distribution tooling
> out there that does the same too) so I wouldn't be too quick to shoot down
> LICENSE files in the root of repositories.
> 
> Cheers,
> Ben

That ship has long sailed. 
At least for frameworks and most of plasma has been converted.

David

Re: Move Licentia to KDEREVIEW

[David Redondo]

Am Montag, 11. Juli 2022, 13:34:14 CEST schrieb Kevin Kofler:
> David Redondo wrote:
> > Am Montag, 11. Juli 2022, 12:37:09 CEST schrieben Sie:
> >> Please note that Gitlab and other places still do rely on LICENSE (or
> >> COPYING) files being present (and I guarantee there is distribution
> >> tooling out there that does the same too) so I wouldn't be too quick to
> >> shoot down LICENSE files in the root of repositories.
> >> 
> >> Cheers,
> >> Ben
> > 
> > That ship has long sailed.
> > At least for frameworks and most of plasma has been converted.
> 
> In the case of the GNU licenses, it is actually a violation of the license
> to not ship a LICENSE/COPYING file along with the project. (This matters as
> soon as you incorporate even a handful lines of third-party code under the
> same license.)
> 
> It is also Fedora policy that upstream SHOULD include a license file and
> that we will file bugs upstream to request them being added where they are
> missing. I believe that Fedora is not the only distribution with such a
> policy.
> 
> So any commits removing license files ought to be reverted ASAP. A pointer
> is not enough.
> 
> Kevin Kofler

Do the licenses really require these specially named files? Note that all
used licenses in the repo are all included in the repos in a LICENSES folder.
it would be a massive oversight and afaik there were never complains from 
fedora when this was started three years ago (https://phabricator.kde.org/
T11550)

David

Proposal for using gitlab for kdereview process

[David Redondo]

Hi,

I observed that participation in kdereview is fairly low. Usually only the 
same few people participate (I have to admit this does not include me either).
Further follow up to their comments tends sometimes to be slow or is missed. 
Sometimes it fizzles out completely.
I think nowadays we have better tools to streamline the whole process, which 
we are familiar with and make the barrier to participation lower. My idea is 
to use Gitlab which we use for normal code review also for the kdereview 
process. For example it could be as follows
- Announce the intention to go through kdereview as usual to kde-core-devel
- Create a MR in your project's repo from master branch into an empty 
kdereview branch
- Could copy the sanity checklist [1] as task list and check things there
- Reviewers can leave review comments in the familiar web interface
- Commits that fix review comments are pushed to master branch and so update 
the code seen in the MR
- Once the reviewers are satisfied and their feedback incorporated, they 
approve the MR and it can be closed

Thoughts?

David



[1] https://community.kde.org/ReleasingSoftware#Sanity_Checklist

Re: Proposal for using gitlab for kdereview process

[David Redondo]

Am Samstag, 18. Februar 2023, 12:02:38 CET schrieben Sie:
> 
> I'm not convinced more paper work is going to help us increase the number of
> participants in the review process (which is imho the big issue), 

Hi Albert, I don't think it's will be paperwork, usually the mentioned 
checklist was the first thing Harald links to people and is already mentioned 
on the kdereview wiki page as things people will look at.

> but if you're willing to document all this properly I'm happy to give it a 
try and  be proven wrong :)


I will try to write something then for the wiki if noone objects.

David

Re: Proposal for using gitlab for kdereview process

[David Redondo]

So there are two new kdereview requests using gitlab issues now instead of my 
more complicated idea of merge requests. I imagined a MR to have advantages 
for codereview but an issue seems to be less complicated (no need to have an 
empty orphan branch, etc..), so maybe we should go with that.

David

Re: We need to remove exec_program() from our Cmake files

[David Redondo]

Am Donnerstag, 26. Oktober 2023, 03:49:57 CEST schrieb Ömer Fadıl USTA:
> 
> ```
> The exec_program()
>  rogram> command, which has been deprecated since CMake 3.0, has been removed
> by policy CMP0153
> .
> Use the execute_process()
>  cute_process> command instead.
> ```
This is behind a policy so if we don't have

cmake_minimum_required(VERSION 3.28)

in my understanding we can continue to call it for now and not have to rush 
though it.
Otherwise we would have to change things every time a policy changes behavior.

David

Re: Re: Proposal to Update Minimum CMake Version to 3.22

[David Redondo]

Am Mittwoch, 9. April 2025, 21:44 schrieb Ingo Klöcker:
> On Mittwoch, 9. April 2025 15:39:17 Mitteleuropäische Sommerzeit Kevin Kofler 
> wrote:
> > David Redondo wrote:
> > > FWIW Frameworks Qt minimum is still 6.5 and will be 6.6 once 6.9 releases.
> 
> The rule is current minor version of Qt minus 2. As a matter of fact, Albert 
> has just raised the minimum Qt required by KDE Frameworks to 6.7.
> https://invent.kde.org/frameworks/kconfig/-/commit/
> 1e40d290384e36b079dcb190b59a566adfdbddd0
> 
> Regards,
> Ingo
> 

Yes I made a calculation error. I had "last 3 versions" on my mind
and subtracted 3 instead of 2. I should have double checked.

Apologies,
David

Re: Proposal to Update Minimum CMake Version to 3.22

[David Redondo]

Am Sonntag, 30. März 2025, 14:13 schrieb Ömer Fadıl USTA:
> Dear KDE Core Development Team,
> 
> I hope this message finds you well. I would like to propose an update to
> the minimum required version of CMake for KDE Frameworks and KDE Plasma
> projects, raising it from 3.16 to 3.22.
> 
> The primary reason for this change is that there are currently no
> distributions that still utilize CMake 3.16. While this transition may be
> considered late for KDE 6.4, it is essential for KDE 6.5. Our existing
> Continuous Integration (CI) systems are already using versions of CMake
> that are newer than 3.16, meaning we do not perform checks for CMake 3.16
> compu7yyyatibility.
> 
> Furthermore, with the release of Qt 6.9 stable, the minimum required
> version of CMake for building Qt has been updated to 3.22, as noted in the
> Qt 6.9 release notes[1]. This change emphasizes the need for us to align
> our CMake version with the latest requirements to ensure compatibility and
> maintainability.

FWIW Frameworks Qt minimum is still 6.5 and will be 6.6 once 6.9 releases.

David