New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add philosophy/principles #16
Comments
Lets make sure to document the "Why?" as well as the "What?" when documenting the philosophy/principles. I'd specifically like to fully understand the "Why?" on the following:
|
I do agree on the necessity to document the reason behind each principle. By the way, please feel free to suggest new principles or changes to them right now, as they will we harder to amend later on.
This fits in a wider principle of “We should be able to build all packages from source without relying on pre-built binaries”. The reasoning behind this guidance is to ensure the auditability of the packages. It’s hard to audit binaries, but less hard to audit source code. Auditing source code is sufficient as long as we can ensure that it matches the built binaries (see “Reproducible builds” principle higher in this thread). The scope of this principle includes the toolchain that is used for building the packages (otherwise we need to trust yet another unauditable set of binaries). Unfortunately, it’s not possible to rebuild the exact same toolchain as provided by the reMarkable company, because its sources were not distributed. So, the Docker images aim at recreating a similar build environment which can itself be built from source. A current limitation of this guidance is with the closed-source |
We should probably ask remarkable for the source of the toolchain, since most items in it are under GPL. We could at least get source/configs for enough of it to keep what we build close. |
Things I think we should think about:
|
I find that a good idea. Might also be a way to safely incorporate the rm hacks which a lot of people use nowadays. That could also offer people who don't really care how they build their software to use the rM toolchain or other binaries of questionable source. We could also add non opensource packages for e.g. template management or others could provide packages for their solutions that can't be checked well (example with the recent distro and the new tool). Looking at sourceforge being still a thing, I guess that many Windows or output focused developers who don't care about their source code or automatic building could add their software binaries there from their website or whatnot. A question I would have is then, whether we do a nonfree-testing and nonfree-stable or have a common testing branch.
I fully agree with our opinion on this. The package manager should enable an easy ecosystem especially for people who don't care about checking the origin of every line of source as long as they have access to fun mods and don't catch malware. We should still try to encourage freedom, security, scruteny and so on, but ease of use should really be the first priority here. People who really care about the source can usually still build that project from source anyways. We should mainly distribute this software and not recompile everything without any exception. At the end most users won't care anyways.
I'm pretty much torn on this one. I guess that comes back to how sophisticated we want the testing -> stable transition to be. I guess that makes this point another topic we already started elsewhere.
I would say: Best-effort community driven but no guarantees. There will be packages that get dormant either because of lack of interest, no more releases from the dev or other reasons. We should strive to be as active as possible but don't make end users think that we "will be perfect". Only time can tell. |
If we package something we should probably also put in place some sort of automation to open a task when a new release has been pushed for it. That would at least help us keep an eye on what needs to be done, and let others pick up on it. |
Agreed. I’m moving this suggestion to a separate issue. |
I’m not in favor of a non-free repository for now, for two reasons:
We can always package the rM hacks safely by only distributing the binary patches. Anyway, making a non-free repository will not instantly enable us to redistribute xochitl, as we’d need to get an agreement with reMarkable AS first, which I doubt we’ll get. Is there a non-free template management tool that runs on the reMarkable?
I don’t see where freedom conflicts with ease of use in this case. I think we should prioritize both.
Agreed. |
Can we close this issue? (Is the README or other place documenting free software principles enough?) |
please open if you think this needs re-addressing |
there are a few principled decisions about the repo that should be made clear / explicit in the repository's README. i'm thinking about things like:
The text was updated successfully, but these errors were encountered: