---
title: "Devlog - week 3, 4 and 5 of 52"
date: 2023-02-05
draft: false
tags:
- devlog
- decision
---
I spent too much time rethinking the organization of the websites. This is an unacceptable yak shaving for an alpha-state project.
I switched from Git and Codeberg to [Pijul](https://pijul.org/) and [Nest](https://nest.pijul.com/mzan/dokmelody-bootstrapping). Some reasons are:
- Pijul supports merges and forks of a codebase in a better way respect Git, because it remembers the merge operations done. This feature fits well with the [ADR-004: Favors branching and forking of Dokmelody](https://bootstrapping.dokmelody.org/docs/topics/references/ADR/ADR-004-favours-project-branching-and-forking.html).
- I want to learn Pijul, and maybe I like to use Pijul "theory of patches" into some parts of Dokmelody system, for managing the forks of data between different communities.
- There are future plans, for a self-hostable Nest. Something like [Fossil](https://fossil-scm.org).
- Nest has also a "discussion" section.
I'm using [DITA](https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture) for [Dokmelody documentation](https://bootstrapping.dokmelody.org/docs/topics/dokmelody/about-dokmelody.html). The reasons are:
- navigation in documentation is very easy
- favours the use and reuse of chunks of information
I switched to MIT License. The reasons are described in [ADR-003: Use MIT and CC-BY-4.0 licenses](https://bootstrapping.dokmelody.org/docs/topics/references/ADR/ADR-003-use-MIT-and-CC-BY-licenses.html):
I decided to use a [redo](https://github.com/apenwarr/redo) build system, respect a traditional "make-like" approach. A make-file is essentially a bottom-up specification of how to build the system starting from initial source files. A "redo" approach is a top-down specification of how to build a product, checking if some parts do not need an update. This approach is more similar to normal code, because every part of a build is like a function that can call other functions.