Managing Github Milestones

Discussion about the project in general, organization, website, or any other details that aren't directly about the game.
Message
Author
User avatar
Vezzra
Release Manager, Design
Posts: 5059
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Managing Github Milestones

#16 Post by Vezzra » Sun Sep 22, 2019 2:03 pm

Ok, that went a bit quicker than I anticipated. The milestones have been updated and the "priority:*" labels have been added. Here is a summary of how things are going to work now (mostly a repetition/quote of the proposal above, with subsequent suggestions incorporated if they had been accepted, and maybe some adjustments here and there):

We now have only one release milestone, which will be labelled "next release" as long as the version number of the next release hasn't been determined. Once that has happened, it will be renamed to the version number (using the "vX.Y.Z" scheme). Of the open issues/PRs only those deemed mandatory/required for the release get assigned to that milestone. Issues/PRs that are only "optional" won't get a milestone, so being optional for the release will be indicated by not having a milestone (which is the default, obviously).

Distinguishing between issues/PRs that don't need a milstone (like those infrastructure issues/PRs), issues/PRs that are optional, and issues/PRs where a decision about if they are mandatory or not hasn't been made yet won't be done anymore (which shouldn't be a problem, I don't think that has made much of a difference in the past).

When an "optional" issue/PR (which hasn't been assigned to a milestone yet) gets closed/merged, it must get a milestone assigned at that point. When that happens, there are two different cases:
  • In case the release branch for the next release hasn't been created yet, it gets assigned to the release milestone ("next release"/"vX.Y.Z"), as all issues/PRs resolved/merged at that point are going to be part of the next release.
  • If the release branch for the new release has already been created, it depends on if the fix for the resolved issue or the merged PR becomes part (gets cherry picked into) the release branch. If yes, assign the issue/PR to the release milestone. If not, assign it to a "post release" milestone that gets created together with the release branch (giving the "post release" milestone a different meaning than it had until now!).
Once a new stable release is out, close the corresponding release milestone. Then rename the "post release" milestone to "next release" so it becomes the new release milestone. As it already contains all closed/merged issues/PRs that didn't get into the last release, but will of course be in the next release, all those issues/PRs will thus already be assigned to the new release milestone, as they should. No further action required.

To help with prioritizing of issues/PRs within their assigned milestones, two new labels have been introduced: "priority:high" and "priority:low" (the "labels.md" file which contains the descriptions of the different labels and their categories has already been updated accordingly). Use these to tag certain issues/PRs as of especially high or low importance/urgency. "Standard"/"normal"/"medium" priority will be indicated by not having a "priority" label assigned, which is obviously the default and should apply to the majority of issues/PRs.

Typical "high priority" issues/PRs would be critical/game breaking bugs or the main features of the next/upcoming release. As much as possible and reasonable, such issues/PRs should receive the attention of developers and contributers first, before turning to other stuff.

Typical "low priority" issues/PRs would be cosmetical bugs, bugs that are more of a minor annoyance than something that actually impedes gameplay, nice-to-have but not really important feature requests etc. In short things that can, and in certain cases like when we are in the stage of rolling out another stable release, even should be set aside for more important stuff (so they don't consume valuable dev manpower when it's needed elsewhere).

I guess it would be good to put this explanation/description somewhere we can easily refer people to (having it only here, buried a thread, might not be enough). Any suggestions? A wiki page perhaps?

For the upcoming 0.4.9 release I've already created the corresponding milestone and, in a first pass, assigned all issues/PRs I deemed important for that release to it (as well as all issues/PRs that have been resolved/merged since 0.4.8 of course). I then removed the old "next release" milestone from all other issues/PRs and deleted it, so those "optional" issues/PRs are, as intended, without milestone now.

Except for one of my old issues, I haven't assigned any priority labels so far. Feel free to assign those to issues/PRs as you see fit.

If you have any questions, comments, objections, corrections, ideas - feel free to post them here.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12484
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Managing Github Milestones

#17 Post by Geoff the Medio » Sun Sep 22, 2019 10:13 pm

I want a way to mark a pull request or issue as something that is definitely not to be addressed in the next release... So a "post release" or "after next release" milestone that is always available. This is not "optional" for the next release; it is definitely not to be included in it.

o01eg
Programmer
Posts: 569
Joined: Sat Dec 10, 2011 5:46 am

Re: Managing Github Milestones

#18 Post by o01eg » Sun Sep 22, 2019 10:51 pm

I suppose it better also to distinguish issues/PRs those which doesn't break compatibility and could be applied in release branch and get into point-release, and those which breaks compatibility and requires next release.
Gentoo Linux x64, gcc-9.2, boost-1.71.0
Ubuntu Server 18.04 x64, gcc-7.4, boost-1.65.1
Welcome to slow multiplayer game at freeorion-lt.dedyn.io. Version 2019-12-03.c0eb3bb.
Donates are welcome: BTC:14XLekD9ifwqLtZX4iteepvbLQNYVG87zK

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12484
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Managing Github Milestones

#19 Post by Geoff the Medio » Mon Sep 23, 2019 8:22 am

It's not so much a compatibility-breaking issue as it is something being a major or complicates complicated change that will likely require extensive testing, debugging, or balance before it should be included. For example, Government is a whole new game system, mechanic, interface, scripting, and set of content that is high priority for post v0.4.9 but is definitely not appropriate to include in v0.4.9. Changes that break compatibility aren't ideal but aren't necessarily banned for imminent next release merging if they are otherwise important and relevant... Like bug fixes or similar that require substantial disruptive changes.

User avatar
Vezzra
Release Manager, Design
Posts: 5059
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Managing Github Milestones

#20 Post by Vezzra » Mon Sep 23, 2019 11:03 am

Geoff the Medio wrote:
Sun Sep 22, 2019 10:13 pm
I want a way to mark a pull request or issue as something that is definitely not to be addressed in the next release... So a "post release" or "after next release" milestone that is always available. This is not "optional" for the next release; it is definitely not to be included in it.
Well, the "post release" milestone still exists in the new system, but was only intended for issues/PRs that get resolved/merged after the creation of a release branch, but not cherry-picked into it (a significant change of meaning of course).

The most obvious solution to achieve what you're requesting would be to give that "post release" milestone its original meaning back (more or less): instead of creating it when the release branch for a new release gets created, create it once we get to the stage in preparing for a new release where we need to make that distinction (of what should go into, can go into, and must not go into the release). Assign all issues/PRs to it that get resolved/merged, but not cherry picked into the release branch, and all issues/PRs that should not get into the release, to the "post release" milestone.

I'd expect that point to be typically when we rename the until then generic "next release" milestone to the "vX.Y.Z" release milestone.

Of course, this requires us to go over all the open issues/PRs which are assigned to the "post release" milestone after the release is out, as that milestone will become the new "next release" milestone. Only issues/PRs which are considered to be required/mandatory for the next release should remain assigned to this milestone, the rest needs to be unassigned to indicate that they are only considered optional for the next release.

Does that adjustment to the new system sufficiently address your concern?

User avatar
Vezzra
Release Manager, Design
Posts: 5059
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Managing Github Milestones

#21 Post by Vezzra » Mon Sep 23, 2019 11:08 am

o01eg wrote:
Sun Sep 22, 2019 10:51 pm
I suppose it better also to distinguish issues/PRs those which doesn't break compatibility and could be applied in release branch and get into point-release, and those which breaks compatibility and requires next release.
One way to achive that could be to use the current "status:cherry-pick for release" label to tag PRs that can/should get cherry picked into the last release branch in case we decide to make a bugfix release.

Or, to make things more clear/distinct, we can add a new label (e.g. "status:backport to last release") for that purpose.

Comments, opinions?

EDIT: There is of course the problem of fixes/patches which get committed directly to the repo, without PR. We'd need a way to keep track of those of them that should go into a bugfix release, too. Suggestions?

o01eg
Programmer
Posts: 569
Joined: Sat Dec 10, 2011 5:46 am

Re: Managing Github Milestones

#22 Post by o01eg » Mon Sep 23, 2019 1:46 pm

I think if we have a point-releases it better to have a appropriate milestones for them.
Gentoo Linux x64, gcc-9.2, boost-1.71.0
Ubuntu Server 18.04 x64, gcc-7.4, boost-1.65.1
Welcome to slow multiplayer game at freeorion-lt.dedyn.io. Version 2019-12-03.c0eb3bb.
Donates are welcome: BTC:14XLekD9ifwqLtZX4iteepvbLQNYVG87zK

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12484
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Managing Github Milestones

#23 Post by Geoff the Medio » Mon Sep 23, 2019 2:00 pm

Vezzra wrote:
Mon Sep 23, 2019 11:08 am
There is of course the problem of fixes/patches which get committed directly to the repo, without PR. We'd need a way to keep track of those of them that should go into a bugfix release, too. Suggestions?
Make a pull request with the relevant commits against the release branch.

User avatar
Vezzra
Release Manager, Design
Posts: 5059
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Managing Github Milestones

#24 Post by Vezzra » Wed Sep 25, 2019 12:35 pm

o01eg wrote:
Mon Sep 23, 2019 1:46 pm
I think if we have a point-releases it better to have a appropriate milestones for them.
That's the case anyway. Once we decide to make a bugfix release, a proper milestone will be created, and issues/PRs that should go into that bugfix release will be assigned to that milestone.

However, we probably want to properly tag PRs which can/should go into a potential bugfix release before such a decision has been made. It's for that purpose a "backport to last release" label would be helpful.

User avatar
Vezzra
Release Manager, Design
Posts: 5059
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Managing Github Milestones

#25 Post by Vezzra » Wed Sep 25, 2019 12:37 pm

Geoff the Medio wrote:
Mon Sep 23, 2019 2:00 pm
Make a pull request with the relevant commits against the release branch.
Ah yes, of course, that would be an obvious way to do this.

User avatar
Vezzra
Release Manager, Design
Posts: 5059
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Managing Github Milestones

#26 Post by Vezzra » Wed Sep 25, 2019 1:03 pm

I have created a "post release" milestone on our github repo. Please assign issues/PRs that should not be addressed in/incorporated into the upcoming release to this milestone.

Post Reply