README.md

@@ -7,18 +7,8 @@ npm run docs:build
 ## Testing localy
 npm run docs:dev
 
-## Manually deploying to a server usign sftp
+## Manually deploying to a server
 pushd .vitepress/dist/ ; echo "put -r *" | sftp -b - -N user@server.domain.tld:www ; popd
 
-## Automatically deploying to a server with forgejo action
-Development is taking place in the main branch, or in feature branches that are then merged into main. 
-To deploy the web site to production server the changes in main branch are merged to the prod branch, which is triggering the deploy action, defined in .forgejo/workflows/deploy.yaml 
-This action builds the web site (`npm run docs:build`) and then deploys it to the production server using sftp with public/private key authentiction
-
-You can use the script in bin/push-to-prod.sh to perform the merge of main branch into prod branch 
-
-if you forked this repository, you need to create the secrets needed by the deploy action (in repository settings->actions->secrets) :  
- - DEPLOY_USER : OS user to connect to production server 
- - DEPLOY_TARGET : sftp target where the web site has to be deployed, in the form of server.domain.tld:path
- - DEPLOY_SSH_PRIVATE_KEY : private ssh key used to authenticate with the server
-and configure the server witht the public key corresponding to DEPLOY_SSH_PRIVATE_KEY
+## Automatically deploying to a server
+check the action in .forgejo/workflows/deploy.yaml

bin/push-to-prod.sh

@@ -1,12 +1,6 @@
-#!/usr/bin/env bash
+#!/bin/bash
 # push main to prod (which will trigger the deploy action)
-CURR_BRANCH=$(git symbolic-ref --short HEAD)
-if [[ ${CURR_BRANCH} == "main" ]]; then 
-  echo pushing main to prod...
 git checkout prod
 git merge --ff-only main
 git push origin prod
 git checkout main
-else
-  echo "This script is meant to be run from the main branch!"
-fi

technical-principles.md

@@ -1,34 +1,2 @@
 # Technical principles
 
-## KISS principle
-"Keep it simple, stupid!"
-
-## Do not reinvent the wheel
-
-## There is only one timezone
-Experience has showned that using multiple timezones for the servers of an infrastructure is a receipe for disaster. 
-Also, using the timezone of one contry for an international project is a source of confusion and headackes. 
-Especially when that timezone is subject to daylight saving changes that are causing the clock to jump 1 hour forward or backward twice a year.
-The only sensible choice is to set the servers time to UTC and to transalte the timestamps to the user's timezone when displaying them. 
-
-This is strongly opinion based. And we may not not all agree on the subject. This is why we will make sure that it is easy for the users to choose their prefered timezone for setting up their servers. 
-
-## Eat your own food
-The project is bootstrapped using a hosting infrastructure thagtis based on Proxmox, Debian and YunoHost. 
-But the goal is to host the project using itself as soon as possible. That is using NixOS servers managed with the tools and principles developed by the NixiN project.
-Currently only the forgejo action runners used for CI/CD are hosted on NixOS servers. 
-
-## CI/CD
-
-## Focus on user experience
-
-## Prioritize security
-
-## No premature performance optimization
-Use best practices to write efficient code but do not write overly complicated solutions based on a-priori thinking of performanc e issue.
-Only optimize what has been tested to be an issue.
-
-## Do fast prototypes and releases cycles.
-Even though we think that Rust would be a better language for developing the tools of the project we are starting the first version using Go because it is faster to develop with it and easier to find contributors with this langages.
-
-