Binaries organisation

Story

We (a colleague [referred to as "he" in the following text] and pinage404) used git-gamble at work

He was not used to using TDD nor TCR

The fear of losing code led to an anti-pattern : before gambling, he took a lot of time to read the code carefully, compile it and execute it in his head, which slowed down the group

This strong methodology should lead you to let yourself be carried along by the tools

He recommended limiting the duration of iterations

git-gamble has been used by several groups and pinage404 has seen this anti-pattern several times

Context and Problem Statement

To solve the problem of iteration duration, another tool has been created since 2022-07-11, but it is neither documented nor easily distributed

The first version of git-time-keeper was written in Bash, and works most of the time, in order to have a more stable experience, it will be rewritten in Rust

git-gamble and git-time-keeper are tools that work independently and can be used together for an optimal experience

How to create, maintain and distribute several tools ?

Decision Drivers

• from the maintainer's point of view
  • easy to set up
  • easy to maintain
  • easy to distribute
  • avoid duplication of configuration and utilities
• from the user's point of view
  • easy to install
  • easy to use
  • easy to understand that each tool can be used separately
  • easy to use tools together for an optimal experience

Considered Options

• Repos : several independent repositories
• Workspaces : 1 repository with several Cargo workspaces
• Binaries : 1 repository with 1 crate containing several binaries

Decision Outcome

Chosen option: "Binaries", because this solution seems to have the fewest downsides, see the table below

Pros and Cons of the Options