- 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.
- All the configuration lives in the Config object (or the
tracking objects that it exposes).
- Get data from the config object for the jobs; TODO: give the
jobs a less-clunky interface.
The UI isn't hooked up to the Config object yet, though.
- Let's just have one header definining export- and visibility-
macros for Calamares. They are still selected based on the
export flags (*_PRO), just defined in one header instead of two.
- These methods are used for multi-page view-steps, which are rare.
For all the others, just drop the empty implementation and defer
to the base class.
Each kind of tracking has an associated webpage / URL describing
the policy for that tracking. The Calamares User Guide has some
generic information. When the user clicks on the Help (?) button
in a tracking-option block, go to that URL.
- Enable translations, substitute ShortProductName into string,
- Simplify code for enabling tracking option blocks,
- Set checkboxes based on configuration,
- Read checkboxes when leaving page,
- Don't stretch the tracking option blocks.
- 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
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.
