toltec-dev / organization Goto Github PK

We currently don't have a security policy defined. Before "going live" we should probably define that.

it would be really cool if we were able to run a qemu image with arm and emulate the rM execution environment. we could then run tests, take screenshots and do other things from a CI machine

The README should be updated to properly reflect what this repository actually is now.

Instead of installing apps in the /opt folder of the stock system, we could build a custom system image with OpenEmbedded/Yocto and take advantage of the dual-partition setup to install our image in a partition while keeping the official image in the other. The company has published some of the recipes used to build their OE image:

• https://github.com/reMarkable/meta-kf5
• https://github.com/reMarkable/meta-qt5-extra/tree/zero-gravitas
• https://github.com/reMarkable/meta-openembedded/tree/zero-gravitas

This could allow us to control the libraries included on the system and to more easily create the build toolchain since OE can export a toolchain automatically IIRC.

In order to make it faster for us to iterate on the website, it would be good to split it out to it's own repository. That way we can update the text and add updated information without having to go through the rigour that the toltec repo requires.

The published repository runs nginx, which keeps logs about who accesses the files. Collected information is (following default nginx rules):

• Complete IP address.
• Date and time of access.
• HTTP verb, version and response code.
• User agent (including browser name & version, OS name & version).

We should probably define a retention time for this information, and maybe reduce the scope of collected information (e.g. anonymise IP addresses after a given time). The logs could be used anonymously to publish stats about which packages are used.

https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

It would be nice to consume an existing standard. Hopefully this issue can serve as a place to persist information on why or why not XDG desktop files might be a good fit.

Importantly, I think it is worth mentioning that there are two mechanisms to extend the recognized keys supported by the format:

Extending the format

If the standard is to be amended with a new {key,value} pair which should be applicable to all supporting parties, a group discussion will take place. This is the preferred method for introducing changes. If one particular party wishes to add a field for personal use, they should prefix the key with the string X-PRODUCT, e.g. X-NewDesktop-Foo, following the precedent set by other IETF and RFC standards.

Alternatively, fields can be placed in their own group, where they may then have arbitrary key names. If this is the case, the group should follow the scheme outlined above, i.e. [X-PRODUCT GROUPNAME] or something similar. These steps will avoid namespace clashes between different yet similar environments.

Hi,

a successor to the known draft format is currently in the works. For that we may need a name in case we don't decide on using XDG Desktop Entries.

How to get involved

Until Jan 20th 5 PM UTC, you can propose new names here. Please just comment with a name as a bullet point (prefixed by - or equivalent) and nothing else.

Discussions are supposed to be happening either in this gh-discussion or the IRC channel #remarkable on freenode (or matrix/discord the bridges).

Again, please do not comment or discuss on proposals in this issue. Use the above means.

Until Jan 24th 5 PM UTC will be time for yet more discussion, but no new name. After this the polling phase will start.

Until Jan 28th 3 PM UTC will be the time to give your decision on what name you like. I'll add a link to a poll here and announce it in the IRC as well.

Final poll options

Will be listed here on Jan 20th 5 PM UTC

Poll

Will be listed here on Jan 24th 5 PM UTC and available until until Jan 28th 3 PM UTC. I'll likely publish the results here as well.

Update: The Poll was posted repeatedly on Discord. For results see below.

This issue continues the original "Project logo" issue toltec-dev/toltec#194.

Goal is to use the logo we have as a template to create new smaller versions e.g for:

• toltec-dev's GitHub organization logo
• Website favicon
• Readme title logo

For reference, here is the current (first) project logo in full size:

(Resized versions)

It might be good to send a message to a user on update or upgrade that warns them of upcoming changes, or issues that they will need to be wary of. A good example of this would be the 2.6 upgrade breaking some packages.

We should have a document that outlines our standard process for various things. That way we can reference it to see if we have rules for something or not. A central location will be easier than trying to scan all the meeting notes for decisions where we define how something is done.