sunpy: Milestones, bugfixes, oh my.

This is a infrastructure issue to solicit input on what people think the role of milestones should play.

Currently we have two bots, one which checks all PRs have milestones and one which backports PRs based on labels.

This ends up in a bit of a weird workflow (imo) where we are duplicating metadata over labels and milestones and we end up with milestones not really meaning very much:

Open a PR to master, milestone it 1.0.x and label it backport 1.0 and backport 1.1 these two actions are duplicating information.
Merge the PR, the bot runs and two backport PRs are opened.
Milestone the backport PR to 1.1 1.1.x and the PR to 1.0 1.0.x.
Merge the PRs, we now have two merged PRs milestoned 1.0.x so when we come to look at doing a release we have a bunch of PRs in there that aren’t actually on that branch.

Proposal:

We do not milestone PRs to master. (This needs a change to the bot to ignore certain base branches).
We milestone (maybe automatically) PRs to backport branches.

This would allow us to better keep track of merged PRs for releases?

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 32 (31 by maintainers)

Most upvoted comments

We only assign milestones to issues that would block a release. These are normally major 🔥 bugs or infrastructure issues that actually prevent a release. The reasoning behind this is that we were always moving issues from one milestone to the next because nobody was working on them.

Given that SunPy operates on a almost entirely voluntary basis we can’t really have deadlines or really even priorities on issues imo. We have been happily using milestones as a release marker for PRs for a while, but the backport bot has changed up our workflow enough that I thought it would be worth reconsidering.

Cadair on Mar 19, 2020