Implement the process for moving packages from testing to stable

[matteodelabre]

This creates the docs/branches.md document which explains what the two release branches are, which one users should choose, and how the transition of packages from one branch to another is handled.

It also updates docs/package.md to add related information about the maintainer field.

This implements the proposal in #20, and closes #20 as a consequence.

[matteodelabre]

This is mostly RFC, I tried to implement what we discussed, but please point out any problems in the documents.

[Eeems]

@matteodelabre If this is a RFC right now, might as well convert it to a draft until we decide it's ready.

[Eeems]

Just reviewed the content and it looks good to me. It would be nice to set up automation as part of this PR to create the merge window PR on a schedule as well.

[raisjn]

what's the process of becoming a maintainer and are the expectations of maintainers outlined somewhere?

[matteodelabre]

Just reviewed the content and it looks good to me. It would be nice to set up automation as part of this PR to create the merge window PR on a schedule as well.

Should this automatically-created PR contain all of the package/ directory from the testing branch? I don’t think we can create empty PRs.

[matteodelabre]

what's the process of becoming a maintainer and are the expectations of maintainers outlined somewhere?

The process by which a maintainer is assigned to a package is described in this PR. As the document says, they are expected to review PRs regarding the packages they maintain. The process for adding a new repository maintainer is not outlined here, and I’d say it’s out of the scope of this PR.

[Eeems]

Just reviewed the content and it looks good to me. It would be nice to set up automation as part of this PR to create the merge window PR on a schedule as well.

Should this automatically-created PR contain all of the package/ directory from the testing branch? I don’t think we can create empty PRs.

I'd say no, likely we should just have a dummy file that we bump a timestamp in or something.

[matteodelabre]

It turns out we can actually create empty PRs, by adding an empty commit to a branch (with git commit --allow-empty).

[matteodelabre]

I think it’s best if we move forward with stabilizing the actual merge process then implement automation in a future PR.

[raisjn]

looks good to me. thanks for the update around bugfixes!

[matteodelabre]

Just needed to fix a link and add instructions for switching to testing before merging.

[matteodelabre]

If you still agree with this change set, could you re-approve the PR @raisjnn? Your review was dismissed since I changed the link in the README and added instructions to switch to testing. Thanks!

[raisjn]

thanks for adding the note about bug fixes!