napcok/calamares
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
5160fdc26a
calamares/src/modules/tracking/CMakeLists.txt

27 lines
562 B
CMake
Raw Normal View History

REUSE: Giant boilerplate cleanup - point to main Calamares site in the 'part of' headers instead of to github (this is the "this file is part of Calamares" opening line for most files). - remove boilerplate from all source files, CMake modules and completions, this is the 3-paragraph summary of the GPL-3.0-or-later, which has a meaning entirely covered by the SPDX tag.
2020-08-25 16:05:56 +02:00
# === This file is part of Calamares - <https://calamares.io> ===
REUSE: (BSD-2-Clause) all CMakeLists The build instructions are not that interesting, it's a toss-up between CC0 and BSD-2, but because other CMake bits are BSD-2-Clause, apply that to more CMakeLists. The copyright date isn't all that accurate, but these are just inconsequential files. While here, tidy up and get rid of some useless intermediates.
2020-08-26 00:24:52 +02:00
#
# SPDX-FileCopyrightText: 2020 Adriaan de Groot <groot@kde.org>
# SPDX-License-Identifier: BSD-2-Clause
#
Telemetry stub. This is experimental, off-by-default, code for developing a telemetry / tracking configuration module. It is preliminary work for issue #628, but also for KDE Neon configuration. Any telemetry should conform to the KDE Telemetry Policy [1] or similar Free Software telemetry policy (e.g. the Mozilla one). [1] https://community.kde.org/Policies/Telemetry_Policy Initial idea is to distinguish three kinds of tracking: - installs. This tracks that OS <foo> has been installed somewhere. It might send some machine information to a remote server. - machines. This enables some kind of machine tracking in the installed system, for instance it could enable popcon on Debian, or periodic phone-home-pings. - users. This enables some kind of telemetry / tracking on the installed user in the system. A simple and transparent setting is to enable install-tracking and set it to opt-in, and disable machine and user tracking. Explain to the user that <foo> would like to know when <foo> is installed, and that the following information <d1>, <d2> will be sent to <url> in accordance to the <foo> telemetry policy at <url2>. Work in this branch is subject to VDG review for the visuals, and privacy oversight by whatever group is responsible for <foo> privacy. Note that this module makes it *possible* for telemetry configuration to be visible inside the installer; what distro's do with telemetry already is entirely outside the scope of this configuration module.
2017-08-29 14:00:37 +02:00
calamares_add_plugin( tracking
TYPE viewmodule
EXPORT_MACRO PLUGINDLLEXPORT_PRO
SOURCES
[tracking] Add a Config object
2020-05-12 14:24:33 +02:00
Config.cpp
[tracking] hook the install-tracking job into the build. (it doesn't work yet, though .. multi-threading issues).
2017-11-09 11:45:25 +01:00
TrackingJobs.cpp
Telemetry stub. This is experimental, off-by-default, code for developing a telemetry / tracking configuration module. It is preliminary work for issue #628, but also for KDE Neon configuration. Any telemetry should conform to the KDE Telemetry Policy [1] or similar Free Software telemetry policy (e.g. the Mozilla one). [1] https://community.kde.org/Policies/Telemetry_Policy Initial idea is to distinguish three kinds of tracking: - installs. This tracks that OS <foo> has been installed somewhere. It might send some machine information to a remote server. - machines. This enables some kind of machine tracking in the installed system, for instance it could enable popcon on Debian, or periodic phone-home-pings. - users. This enables some kind of telemetry / tracking on the installed user in the system. A simple and transparent setting is to enable install-tracking and set it to opt-in, and disable machine and user tracking. Explain to the user that <foo> would like to know when <foo> is installed, and that the following information <d1>, <d2> will be sent to <url> in accordance to the <foo> telemetry policy at <url2>. Work in this branch is subject to VDG review for the visuals, and privacy oversight by whatever group is responsible for <foo> privacy. Note that this module makes it *possible* for telemetry configuration to be visible inside the installer; what distro's do with telemetry already is entirely outside the scope of this configuration module.
2017-08-29 14:00:37 +02:00
TrackingPage.cpp
[tracking] hook the install-tracking job into the build. (it doesn't work yet, though .. multi-threading issues).
2017-11-09 11:45:25 +01:00
TrackingViewStep.cpp
Telemetry stub. This is experimental, off-by-default, code for developing a telemetry / tracking configuration module. It is preliminary work for issue #628, but also for KDE Neon configuration. Any telemetry should conform to the KDE Telemetry Policy [1] or similar Free Software telemetry policy (e.g. the Mozilla one). [1] https://community.kde.org/Policies/Telemetry_Policy Initial idea is to distinguish three kinds of tracking: - installs. This tracks that OS <foo> has been installed somewhere. It might send some machine information to a remote server. - machines. This enables some kind of machine tracking in the installed system, for instance it could enable popcon on Debian, or periodic phone-home-pings. - users. This enables some kind of telemetry / tracking on the installed user in the system. A simple and transparent setting is to enable install-tracking and set it to opt-in, and disable machine and user tracking. Explain to the user that <foo> would like to know when <foo> is installed, and that the following information <d1>, <d2> will be sent to <url> in accordance to the <foo> telemetry policy at <url2>. Work in this branch is subject to VDG review for the visuals, and privacy oversight by whatever group is responsible for <foo> privacy. Note that this module makes it *possible* for telemetry configuration to be visible inside the installer; what distro's do with telemetry already is entirely outside the scope of this configuration module.
2017-08-29 14:00:37 +02:00
UI
page_trackingstep.ui
[tracking] Polish UI a bit - add icons for graphical display of actions - extend description of tracking options - add debug logging - enable next button - show/hide tracking options based on configuration
2017-11-06 16:12:41 +01:00
RESOURCES
page_trackingstep.qrc
Telemetry stub. This is experimental, off-by-default, code for developing a telemetry / tracking configuration module. It is preliminary work for issue #628, but also for KDE Neon configuration. Any telemetry should conform to the KDE Telemetry Policy [1] or similar Free Software telemetry policy (e.g. the Mozilla one). [1] https://community.kde.org/Policies/Telemetry_Policy Initial idea is to distinguish three kinds of tracking: - installs. This tracks that OS <foo> has been installed somewhere. It might send some machine information to a remote server. - machines. This enables some kind of machine tracking in the installed system, for instance it could enable popcon on Debian, or periodic phone-home-pings. - users. This enables some kind of telemetry / tracking on the installed user in the system. A simple and transparent setting is to enable install-tracking and set it to opt-in, and disable machine and user tracking. Explain to the user that <foo> would like to know when <foo> is installed, and that the following information <d1>, <d2> will be sent to <url> in accordance to the <foo> telemetry policy at <url2>. Work in this branch is subject to VDG review for the visuals, and privacy oversight by whatever group is responsible for <foo> privacy. Note that this module makes it *possible* for telemetry configuration to be visible inside the installer; what distro's do with telemetry already is entirely outside the scope of this configuration module.
2017-08-29 14:00:37 +02:00
SHARED_LIB
)
[tracking] Add a test executable - just a stub, hardly tests useful functionality
2020-06-23 14:43:26 +02:00
calamares_add_test(
trackingtest
SOURCES
Tests.cpp
Config.cpp
)
Reference in New Issue Copy Permalink