Project maintenance tools

[acouvreur]

I'm creating this issue to propose multiple tools to ease developer contribution and project maintenance.

• Depenabot for go.mod and .github/workflows files for security fixes and new features
• golangci-lint to introduce a set of rules on the repository
  • An very intersting thing here is the capability to build our own linters.
• mise to extract tool version from a .tool-configs file both in the CI and in the dev environment
• CODEOWNERS file to automatically request a review based on the changed files. We've seen that some people are more familiar with windows, some other with MacOS, some other with embedded system, etc.

To go further, we could also introduce an automatic update mechanism based on conventional commit.

Tools such as release-please or semantic-release are well known in the open source ecosystem.

[soypat]

Dependabot

Dependabot is not great in my opinion and the opinion of many I respect: https://words.filippo.io/dependabot/

golangci lint

Sounds good. Recently merged CI linting into lneto to catch unformatted + go-fixable diffs. The problem this solves is twofold:

• Avoiding formatting noise in future PRs where user runs go formatting automatically on some file that was previously unformatted
• Basically stops style PRs dead in their tracks. If it is not covered by the go-fix or some form of linting then there is no issue. Write the linter first before wanting to change style. This avoids churn due to picky coders.

mise

Huh? Can't we extract tool version with $TOOL --version ? If we can avoid adding dependencies, the better

CODEOWNERS

That sounds pretty cool. Never heard of it but would be super nice to get alerts when someone PRs against your domain.

conventional commit

Theoretically sounds great. In paractice I'd err on the side of not discouraging people who want to simply submit a one-off PR.

release-please or semantic-release

I'd like to have a discussion regarding how we release and better understand how we release before introducing a project that helps us release. Especially some google project that could potentially be sunsetted, as has happened so many times before

[acouvreur]

Dependabot

Dependabot is not great in my opinion and the opinion of many I respect: https://words.filippo.io/dependabot/

I do agree with this, but at the same time it is automated maintenance. I think it's quite important for projects to be up to date and not wait for issues begging to update versions.

There's a lot of customization that can be done that nullifies all of the pain points of dependabot.

Happy to discuss the subject more.

golangci lint

Sounds good. Recently merged CI linting into lneto to catch unformatted + go-fixable diffs. The problem this solves is twofold:

* Avoiding formatting noise in future PRs where user runs go formatting automatically on some file that was previously unformatted

* Basically stops style PRs dead in their tracks. If it is not covered by the go-fix or some form of linting then there is no issue. Write the linter first before wanting to change style. This avoids churn due to picky coders.

Awesome, will add it right away!

mise

Huh? Can't we extract tool version with $TOOL --version ? If we can avoid adding dependencies, the better

This is to facilitate developer setup and CI tool version and developer tool version discrepancy.

Two examples for that:

• golangci lint
• tinygo

Where are the supported versions stored in this project ?

Both quickly evolve with the Go ecosystem and need to catch up the race. Currently, the only version mentioned of tinygo here is latest

bluetooth/.github/workflows/linux.yml

Line 15 in 3639f8e

image: ghcr.io/tinygo-org/tinygo:latest

All versions should be pinned to introduce stability and properly update at a nice pace. (Dependabot comes quite handy here catching incompatibilities at the PR level with automated builds.)

CODEOWNERS

That sounds pretty cool. Never heard of it but would be super nice to get alerts when someone PRs against your domain.

The tinygo-org does not have any team that we could use except the Maintainers team. We should probably create some area-specific teams and use them in the codeowners.

Otherwise, we can simply use the raw account name in the file.

Do you have any knowledge of the teams we could build right now ? Or should we start with a * @tinygo-org/maintainers CODEOWNERS file ?

conventional commit

Theoretically sounds great. In paractice I'd err on the side of not discouraging people who want to simply submit a one-off PR.

release-please or semantic-release

I'd like to have a discussion regarding how we release and better understand how we release before introducing a project that helps us release. Especially some google project that could potentially be sunsetted, as has happened so many times before

Sounds great. Personally, I've been using both in the past, and I quite like release-please because it creates ready to merge pull requests. Like this one: sablierapp/sablier#903