This doesn't seem to have a useful effect for scheduling goal sprints; the big goal sprint this weekend, for instance, isn't here.

This 2020 list is not really relevant in 2024.

The new membership database handles this better and we can run the attendance tool on the day.

So where are we now for this? Since the report is basically already public (for people who know how to edit a URL in the menubar of the browser), it's a bit odd to leave it hanging. Items I can identify in this ticket:

There's no "announce Akademy on the dot" -- would that have fitted into the Social Media schedule? Or "announce on kde-community". I guess those are internal communications, not external Social Media things. There isn't an announcement on the dot: our usual internal news for the KDE community. https://dot.kde.org/2021/09/01/call-hosts-akademy-2022-now-officially-published is the only mention of Akademy 2022 on the dot.

1. Policy on using trademarks

I have gone through Flowchart 1 (in the Encryption Links box in the lower-left of https://www.bis.doc.gov/index.php/encryption-and-export-administration-regulations-ear ) and end up in the Publicly available end state. The instructions on https://www.ecfr.gov/current/title-15/subtitle-B/chapter-VII/subchapter-C/part-742/section-742.15 say "send an email", so that seems like a safe thing to do. Something along the lines of "for authentication (pairing) only, and the source is available at some-KDE-invent-location". I'm counting on the KDE Connect people to accurately characterize the use of crypto in the application. You might have to answer no specifically here, unless you've determined exemption (c) applies, so that you can see if the other not-required cases pop up later in the form.

• Do we update how-to-change-the-rules-of-procedure? What do we do when changing things that were approved once by vote?

Phab doesn't seem like the right place to keep this kind of task. The child tasks were completed but not fully documented, and there has not been much documentation coming forward on newer SoC / SBC efforts.

Phab doesn't seem like the right place to keep this kind of task.

Phab doesn't seem like the right place to keep this kind of task.

Just throwing one thing out there: sr@latin seems to be a KDE-ism, and Qt either doesn't represent it, or uses sr@latn as code-name. There's also complications with zh, apparently, where I get (outside of KDE) contributions where there's a country / region attached (e.g. zh_HK) but the meaning is script (Simplified vs Traditional Chinese), not country. So puzzling things together might usually work, there's a handful of relevant edge cases.

As an update, prompted by @aronkvh 's comments: the actual KDE neon slideshow lives under https://invent.kde.org/neon/neon/calamares-settings , you'll need to find the slideshow.qmland patch that up with suitable QML, or go with an images-only slideshow which is easy to do (list of filenames in YAML) but suffers from scaling issues (although, TBH all of Calamares does).

I've updated the table with myself as contact for Calamares on both sides. @teo is also still around. I've filled in "no" for now. I think I've written this before, but there's these issues:

• (political) Calamares is a distro- and desktop-independent installer. *Not* being a KDE project has value there, although as KDE grows more umbrella-ish the political side is reduced: also with Calamares established now as an independent installer there's less "oh, that's KDE, can't use it for my xfce distro". So .. not much of an issue anymore.
• (administrative) It has its own domain (calamares.io) which is owned by Blue Systems; if I understand the manifesto correctly this would have to be transferred to sysadmin: that is only partly my (the maintainer) decision to make. Besides which I gather sysadmin isn't really jumping at the opportunity to host lots of domains. On the other hand, it's a simple GitHub pages (i.e. Jekyll) site, so it's easy enough to host. So .. a bit of an issue, for administrative reasons.
• (technical) GitHub was, for a while, much nicer than the git hosting provided by KDE. Now with GitLab, I'd say that KDE hosting is nicer. But with the ongoing uncertainty about GL issues versus Bugzilla, that's a reason to stick with GH and one stream of issues. So .. needs clarification, might be blocker.
• (technical) Who's going to do the work of creating importers-and-migrators? (Er .. come to think of it, GL has GH importers that work just fine) So .. resolved.
• (i18n) Existing translation workflow is via Transifex, I would either need to keep that translation source or you'd need to convince me that KDE's translation workflow is effective (and supports Esperanto and Interlingue and ..) and can give the kind of turnaround for Calamares's two-week release schedule. So .. needs explanation.

It might be nice to replace COPYING -- let's not create a new file LICENSE, that's confusing in the face of the REUSE spec -- with a little "This repository uses SPDX identifiers and follows the REUSE specification. You can find the applicable licenses in the LICENSES/ subdirectory. If you have the REUSE tool installed, make show-outbound-licenses and make show-source-licenses will tell you about this respository."

The classic example of Jon's second paragraph is YACC (and Bison), which generates code and adds a big chunk of template code. Or Boost, which has parts intended for header-only use, and so that gets copied all over the place (think of the header as "generated code from the source 'use boost::pointer'"). The template is copyrighted, but in context is liberally licensed.

CC0 is the "long form" of Jon's second suggestion; it is unfortunately long and torturous, but also one of the licenses we might have to deal with anyway for "uncopyrightable". It has a SPDX identifier, CC0-1.0 and is also suggested by REUSE.software.

• If we allow BSD-3-Clause, it should be a separate explicit entry in the alternative-licenses list.
• The official SPDX text has "3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." where the italics indicate that variants exist; the sample text is pretty generic IMO.
• CMake upstream specifically instructs "We do not require any formal copyright assignment or contributor license agreement. Any contributions intentionally sent upstream are presumed to be offered under terms of the OSI-approved BSD 3-clause License. See Copyright.txt for details." (here)

This review should be closed: a change landed via invent that makes it unnecessary (<crypt.h> is no longer used in the users kcm).

There's already a CMake-time check for <crypt.h>, it's just not used. (HAVE_CRYPT_H)

It would be ironic, if the problem was in the find-module, and not in the CMakeLists.txt of kgraphviewer itself, which in some places uses ${graphviz_LIBRARIES} and elsewhere does not. I'll just push a fix to invent.

This looks abandoned or stalled. @michaelh do you have any plans on this front?

@aheinecke patch in bug 415168 fixes the issue by doing the single-RTTI-exported that Volker talks about.

Calling @davidedmundson .. I would migrate this to invent, except in 3c1a34a26dbdf7c123782746881d914cd47b27b6 the similar adjustment for XDG_DATA_DIRS was already removed. We carry this patch, but recent Plasma's no longer set XDG_DATA dir so I think your call on the variable (noone relies on it) is the right one and this can be abandoned.

Moved to invent !40

Migrated to invent, https://invent.kde.org/frameworks/kdesu/-/merge_requests/1

Turns out this was a dup of D13971, which was filed earlier, and landed two weeks after this one.

Pretty much exact same changes were done in D15479

Yeah, let's not then.

Landed in invent with 9dbcc119

Fixed by @rakuco instead.

Re-filed on invent

There is supposedly kernel-level mitigation for this now, although I haven't found it to work; the "weird issues" in this patch never went away so I'm abandoning it in favor of just using sysctl and a pkg-message.

This was entirely the wrong project / community / everything for this to land in.

This looks abandoned with 2 years of no movement. @michaelh do you still feel this is a WIP?

This looks abandoned with 2 years of no movement. @michaelh do you still feel this is a WIP?

This looks abandoned, no movement in over two years. @michaelh did you still want to introduce docId instead of quint64? This diff was supposed to supplant D10851 but seems to have fallen asleep as well. (In retrospect, perhaps I would have suggested first introducing just using docId = quint64; somewhere, to get the more-expressive-type-name part out of the way before real changes)

This looks abandoned, no movement in over two years. @michaelh do you want to explicitly abandon this one, so we have a clean slate for invent? None of the docId type changes seem to have made it to master (see also D10856)

"Overcome by events" as we say in FreeBSD-land

This was fixed independently in 114b349f09