JF002
commented
1 year ago I began using the milestone functionality form Github when I was mostly the only "core developer" of the project. This helped me keeping track of what PR I was currently reviewing and I wanted to be merged for the next release. It is also very helpful to have a quick overview of what have already been done and what to expect for the next release, and it makes the editing of the release note easier.
So yes, this is 100% manual, and it's constantly evolving : I add PR depending on which PR I'm currently reviewing and working on.
I agree that things might have become a bit confusing since we are now multiple core developers: one core developer might add a feature in the milestone that might be removed later on once we talk about this feature and decide that we won't merge it for some reasons. I understand that the author of the PR might feel a bit frustrated to see their PR added and then removed from the next release.
It can be used to see what changes were made between releases in a cleaner format than a list of commits. Is there another way to see which PRs were merged between releases?
If there's an easy way to create release notes without the milestones, we can consider not using the milestones for releases.
I don't think Github provides an easy way to see what PR were merged between 2 tags (or I haven't found it yet). It can easily generate a list of commits that were added between 2 tags, but not a list of PR. If we want to use the list of commits to generate the release note, we'll have to be a lot more strict on the content of commit messages.
If we keep the milestones and want to keep track of the PRs merged, we could add them to the milestone just before merging, or maybe just keep doing things the way we are currently doing. Let me know what you think.
You're right : we should clearly define what are the purposes and the meaning of milestones and approvals.
Here is how I think we are currently using them:
- Approvals : a core developer reviewed the PR and think it's ready to be merged
- Milestone : We try to add all PR that are merged in the milestone, this helps with the release note. We also add PR that are still under review to ask other core-developers to seriously consider that PR.
If I understand correctly, your suggestion is the following:
- core developers approve the PR when they think it's ready
- we merge PRs that receive at least 2 approvals
- we add merged PRs in the milestone.
And I think it makes sense, I would be OK to test it :)
Riksu9000
The way we use milestones is somewhat arbitrary. There's always a single milestone for the next version and we add PRs to that when we want a PR merged for the next release, or just before merging. We sometimes end up having to remove PRs from the milestone. It's a manual process, and a merged PR may accidentally be left out of the milestone.
I was thinking about what the purpose of this system is. The milestone's supposed to tracks progress, but isn't indicative of anything if we may add something to it at any time. It can be used to check for what to review, but you could also filter PRs by approved review, and all the results are in need of a second review to be merged for the next release, which is basically the same.
It can be used to see what changes were made between releases in a cleaner format than a list of commits. Is there another way to see which PRs were merged between releases?
If there's an easy way to create release notes without the milestones, we can consider not using the milestones for releases.
If we keep the milestones and want to keep track of the PRs merged, we could add them to the milestone just before merging, or maybe just keep doing things the way we are currently doing. Let me know what you think.
Relates to #1514, where a maintainer's guide is being added, where the resolution of this issue should be placed.