From a7eb8c75db556f82c8e262ecb11746cd30045c41 Mon Sep 17 00:00:00 2001 From: JohnnyRevay <65253638+jan-revay@users.noreply.github.com> Date: Sat, 18 Nov 2023 18:17:38 +0100 Subject: [PATCH] Update README.md --- README.md | 67 +++++++++++++++++++++++++++---------------------------- 1 file changed, 33 insertions(+), 34 deletions(-) diff --git a/README.md b/README.md index 5aae78af4..33d21c4ad 100644 --- a/README.md +++ b/README.md @@ -18,10 +18,10 @@ After you updated the `initPC` or `dotfiles` repo (e.g. adding a package, changi ## Branches -1. **`LTS`** - debloated, stable, tested, production-ready, and not expected to change in the _yearly horizon_. Only necessary stuff. Possibly useful for detecting whether bugs in the stable branch are caused by the init script or to be used as a substitute for the stable branch while the stable branch has a critical bug. Debloating is done via additional commits on top of the `LTS` branch, therefore syncing `stable` and `LTS` is done via rebasing to preserve the debloating commits on top. -2. **`stable`** - stable, tested, production-ready, and not expected to change much in the _monthly horizon_. -3. **`testing`** - shouldn't be broken or inconsistent most of the time, useful changes from `devel` that are queued to be accepted to the `stable` branch (or rejected). If a change is rejected from `testing` it will be dropped via a commit in `devel` that will be fast-forward merged to the `testing` branch again. -4. **`devel`** - development and experiments, might be inconsistent or broken regularly. Useful, consistent, and fully functional changes from the branch devel might be merged into the branch `testing`. +1. **`LTS`** - debloated, tested, stable, useful, production-ready, and not expected to change in the _yearly horizon_. Only necessary stuff. Possibly useful for detecting whether bugs in the `stable` branch are caused by the init script or to be used as a substitute for the `stable` branch while the `stable` branch has a critical bug. Debloating is done via additional commits on top of the `LTS` branch, therefore syncing `stable` and `LTS` is done via rebasing to preserve the debloating commits on top. +2. **`stable`** - tested, stable, useful, production-ready, and not expected to change much in the _monthly horizon_. +3. **`testing`** - shouldn't be broken or inconsistent most of the time, changes from `devel` that are queued to be accepted to the `stable` branch (or rejected). If a change is rejected from `testing` it will be dropped via a commit in `devel` that will be fast-forward merged to the `testing` branch again. +4. **`devel`** - development and experiments, might be inconsistent or broken regularly. Consistent, and fully functional changes from the branch `devel` might be merged into the branch `testing`. 5. **`feature-`** - all feature branches should be branched off and merged to `devel`. Features and bugfixes of `testing`, `stable` or `LTS` should always go through the `devel` branch first (following the change workflow below). 6. **`archived/-`** - branches archived before a `push --force`. @@ -32,10 +32,10 @@ After you updated the `initPC` or `dotfiles` repo (e.g. adding a package, changi ### Change workflow ```text - functional & tested & not changing, debloated - impl. consistent useful stable & necessary -O------> devel -------------> testing -------------> stable -------------> LTS - ff-only merge ff-only merge rebase + functional & tested, stable, useful not changing, debloated + impl. consistent & production-ready stable & necessary +O------> devel -------------> testing -----------------> stable -----------------> LTS + ff-only merge ff-only merge rebase ``` ## FAQ @@ -55,32 +55,31 @@ TODO ## TODO 1. Merge and deprecate the InitNewPC repo InitPC repo on org GitHub and initAndroid repo. -2. Merge with LogidCfg repo -3. Test the Windows setup script on a VM -4. Create aliases for PowerShell -5. Try merging the apt, flatpak, and snap install commands -6. Have a look at popOS packages and add the useful ones to other init scripts -7. Design a system for applying the configs on all my machines once they +1. Merge with LogidCfg repo +1. Test the Windows setup script on a VM +1. Create aliases for PowerShell +1. Try merging the apt, flatpak, and snap install commands +1. Have a look at popOS packages and add the useful ones to other init scripts +1. Design a system for applying the configs on all my machines once they were updated here. - implement `refresh` alias - add notification to .bashrc if the initPC or dotfiles are not up to date -9. Add more C++ tools from here: -10. Add Bats automated tests -11. Try adding NixOS -12. Create CI tests on GitHub -13. Todos from the repo -14. Make the core Linux init script Debian based (i.e. other distros just add stuff to the Debian base init script) -15. Maybe replace the Debian variants (Ubuntu, PopOS...) with a single Ansible script with conditionals? -16. Do some research on whether snap and flatpak packages work in WSL resp. which alternative package manager to use in WSL -17. Consider running the whole `./run_all.sh` script as sudo and removing `sudo` commands from the script. -18. Shorten the names of branches I use most often devel -> dev, testing -> test -19. Consider using , , or similar libraries (see: and ). -20. Format to max 82 chars in a line. -21. Echo errors to stderr -22. Make the script compliant with Google Bash style guide. -23. Consider running different files in different subshells i.e. not using `source` command. -24. shared_gui_packages_install.sh -25. Automatic formatting of markdown files -26. Format markdown files (add linebreaks, beautify...) -27. Consolidate branches (unmerged feature branches). -28. Backup solution +1. Add more C++ tools from here: +1. Add Bats automated tests +1. Try adding NixOS +1. Create CI tests on GitHub +1. Todos from the repo +1. Make the core Linux init script Debian based (i.e. other distros just add stuff to the Debian base init script) +1. Maybe replace the Debian variants (Ubuntu, PopOS...) with a single Ansible script with conditionals? +1. Do some research on whether snap and flatpak packages work in WSL resp. which alternative package manager to use in WSL +1. Consider running the whole `./run_all.sh` script as sudo and removing `sudo` commands from the script. +1. Consider using , , or similar libraries (see: and ). +1. Format to max 82 chars in a line. +1. Echo errors to stderr +1. Make the script compliant with Google Bash style guide. +1. Consider running different files in different subshells i.e. not using `source` command. +1. shared_gui_packages_install.sh +1. Automatic formatting of markdown files +1. Format markdown files (add linebreaks, beautify...) +1. Consolidate branches (unmerged feature branches). +1. Backup solution