Improving tracey's development process

[Vacyyyy]

I hope that in the future of Rust (and software engineering broadly), a tool like tracey becomes part of standard tooling. Perhaps tracey—or a similar tool—could eventually fall under the umbrella of the Rust Foundation.

That said, tracey’s current development process doesn’t fully align with the workflows it’s meant to support, which can hurt credibility. Respectfully, the process feels somewhat scattered. I propose an overhaul focusing on:

1. Development documentation (not user-facing)
2. Process formalization, including developer experience improvements
3. Adopting and enforcing conventions such as Conventional Commits with scopes

This is not suggesting that tracey should fully and rigorously self-host its own process, nor should it reach the formality of safety-critical software. In the context of Functional Safety, tracey would likely be considered minimally critical safety-wise.

On the tooling side, in my fork at github.com/spynnn-org/tracey, I’ve created a flake.nix usable via nix develop .#. While it doesn’t yet support the dev dependencies under crates/tracey/src/bridge/http/dashboard/, it already improves developer experience and reproducibility. If maintainers like this direction, I’m happy to:

• Add the missing dev dependencies
• Potentially port it to Cachix's Devenv’s devenv.nix format (which is easier to maintain)
• Maintain it for the foreseeable future

Regarding documentation, the current README.md only covers usage. It would be helpful to add sections for development (testing, linting, dev environment, releasing, etc.).

I understand that these proposals may be a significant undertaking. My goal here is to start a discussion, and I’m happy to wait/postpone this if maintainers think it isn't time for this step yet. That said, tracey is intended to be stable (?), and improving its development process could greatly enhance its long-term maintainability. A lot of this can be done incrementally too.

[Vacyyyy]

Enforcing a linear history and commit signing I would also like throw into the disccusion. The just interface should probably be expanded too.

[fasterthanlime]

I’ve recently given commit rights to @bbqsrc, so it’s not just me anymore making decisions here but my 2c are:

• I don’t like merge commits and would like to keep them out of the git history (for reviewability reasons etc.)
• I obviously want tracey to be specified using tracey — Sometimes it drifts a little bit, and the solution to that is obviously more tracey: I’ve gotten started on a pre-commit hook and tracking versioning of rules, etc.
• I don't mind keeping a flake inside the repository, even though I don't use them myself, so they're going to get out of date eventually.
• I personally think commit signing is a waste of time,I could be convinced otherwise if it’s not a huge lift?
• I’m still making big changes to tracey, so it’s not really intended to be stable right now. Maybe we can discuss those again once that design stabilizes.

The documentation certainly needs some work, that’s for sure.

[bbqsrc]

I'm doing a first past on a user's guide at the moment.

[Vacyyyy]

Looking at the amount of work you did again now I was expecting the SemVer 1.0.0 to not be accurate. While it sounds nice, especially long-term, don't you see quite an "administrative" effort in self-hosting tracey? As a user, it is good to at least now have some knowledge of where tracey is gonna be heading, thanks. I am gonna get to work on refining that flake then later today (feel free to assign me if it ever sees issues, I'd be willing to own it).

[Vacyyyy]

I'd like to hear your rough plans for the pre-stable to stable era of tracey.