Conventions in single crate process

Branch names

pending-* branches

The release.sh script automatically creates a pending-foo branch for package foo. It's a signal that others should not upload again when yours is on the way, likely without your changes. You should push it, and merge when the upload is accepted, or delete when rejected. Please do not manage such branches yourself

Since they are managed by ./release.sh, please don't manage them yourself as you will interfere with the working of that script, and other maintainers. The intention is that they should only differ from the master branch by 1 commit, i.e. the dch -r commit created by ./release.sh.

If you want to create separate non-master branches, that is fine - just don't call them pending-* and don't run ./release.sh on those branches. If you want to test your crate, instead run:

cd build && [SOURCEONLY=1] ./build.sh <crate-name> [<old-version>]

omitting the stuff in [...] as needed.

Like many other Debian git repositories, Rust team don't follow "feature branch" practices here. The team generally don't package just 1 or 2 rust crates at a time, but all of its dependencies and sometimes some reverse-dependencies too. So normally a few dozen packages are updated at once. In this context, it's good to merge often, to avoid conflicts with someone else that might also need to touch those too in the next few days.

To match a release (i.e. a .deb or a .dsc file) to a commit, find the commit message that actually says "package: release x.y.z-d". It's commonly followed by a merge commit.

MR branches

TODO: should be discussed in the April 2025 team meeting.

Commit messages

TODO: should be discussed in the April 2025 team meeting.

Patch style

TODO: should be discussed in the April 2025 team meeting.