Managing Github Milestones

Discussion about the project in general, organization, website, or any other details that aren't directly about the game.
Post Reply
Message
Author
LGM-Doyle
Programmer
Posts: 219
Joined: Mon Feb 29, 2016 8:37 pm

Managing Github Milestones

#1 Post by LGM-Doyle » Fri Dec 08, 2017 2:17 pm

EDIT by Vezzra: Split this topic from here. The following quotes are from posts prior to those that have been moved here, which I left in the original thread because only a part of them was about managing milestones:
LGM-Doyle wrote:
Mon Dec 04, 2017 7:55 pm
Could we change the names of the "v0.4.8(optional)" and "post 0.4.8" to something generic? When we release v0.4.8 all the timestamps on those issues will be reset when the issues are moved to the next version number. It is easier to track what issues are hot/current and what issues are not when sorting by timestamp is meaningful.
Vezzra wrote:
Fri Dec 08, 2017 12:53 pm
Could we change the names of the "v0.4.8(optional)" and "post 0.4.8" to something generic? When we release v0.4.8 all the timestamps on those issues will be reset when the issues are moved to the next version number. It is easier to track what issues are hot/current and what issues are not when sorting by timestamp is meaningful.
While I understand and agree that's an issue, how is renaming those milestones to something more generic supposed to solve anything? Once the release is out, I intend to rename "0.4.8 (optional)" instead of making a new milestone and moving all the assigned issues and PRs anyway, so unless the timestamp of issues/PRs are reset when the assigned milestone is just renamed, there shouldn't be a problem with those. And the issues/PRs assigned to "post 0.4.8" will have to be reassigned to the renamed "0.4.8 (optional)", so their timestamp is going to change regardless how "post 0.4.8" has been named...?
</EDIT>

Vezzra, mass changing of milestones causing spurious timestamping is more irksome than a full blown issue.
Vezzra wrote: I intend to rename "0.4.8 (optional)"
This might work, but most other re-labelings, reset the timestamp. We will see.
Vezzra wrote:how is renaming those milestones to something more generic supposed to solve anything?
Milestone names could be choosen that do not require immediately moving many/any issues upon releasing a new version.

The current milestones are "v0.4.8 (manadatory)", "v0.4.8 (optional)" and "post 0.4.8".

One way of interpreting their intent is immediate, near future and far future requirements. Releasing v0.4.8 will not immediately make all of "v0.4.8 (optional)" mandatory for the next version. The version numbers could be stripped from the second two milestones. It would improve their utility.

Looked at another way the current milestones correspond loosely to blockers, non-blockers and feature requests.

And in another way, required, desirable, and wished for.

We need a milestone for blocking issues and required features of the next release version. We could name it "vX.Y.Z".

We need a milestone for non-blocking issues, implemented but non-required features and upcoming requested features. We could name it "optional"

We need a milestone for long term works in progress (WIP) and wished for feature requests. We could name it "wishlist.

If we used milestone names like "vX.Y.Z", "optional" and "wishlist, then after release a new milestone named "vX.Y+1.Z" would be created to which a single feature request is moved from "optional. Otherwise nothing would change.

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

Re: 0.4.8 roadmap

#2 Post by Vezzra » Sun Dec 10, 2017 5:23 pm

LGM-Doyle wrote:This might work, but most other re-labelings, reset the timestamp.
What do you mean by "most other re-labelings"? There are two ways in which milestones of issues/PRs are going to be changed after a release: renaming of a milestone (which should not change the timestamps) and reassigning issues/PRs to another milestone (which of course will change their timestamp). Is there anything else?
The current milestones are "v0.4.8 (manadatory)", "v0.4.8 (optional)" and "post 0.4.8".

One way of interpreting their intent is immediate, near future and far future requirements. [...] Looked at another way the current milestones correspond loosely to blockers, non-blockers and feature requests. [...] And in another way, required, desirable, and wished for.
Erm, not quite. I guess this could be one reason for our misunderstanding: the "mandatory" and "optional" milestones are exactly that (not correspond loosly to ;)), release blocking issues/PRs and those that do not block the release. The purpose of the "post" milestone is to mark issues/PRs which shouldn't be worked upon until after the release. Either because they require too much effort and are not important for the release (so would distract too much dev manpower), or would open a can of worms that would delay the release too much.

Or, to phrase it a bit more to the point: "mandatory" = must go in, "optional" = can go in, "post" = should not go in.

Which means the the "post" milestone only makes sense when we're trying to wrap up a release, which in turn means that after a release all the issues/PRs assigned to the "post" milestone have to be reassigned. Unless I'm missing something obvious here, having more generic names for the "optional" and "post" milestone isn't going to help with that...
Releasing v0.4.8 will not immediately make all of "v0.4.8 (optional)" mandatory for the next version.
Right, which is why I intend to rename the "0.4.8 (optional)" milestone to "0.5 (optional)" (or "next release (optional)" if we haven't decided on the version number of the next release). All the "mandatory" issues/PRs have been closed/merged anyway, which only leaves the issues/PRs assigned to the "post" milestone. These are actually the only ones of concern when it comes to the timestamp problem.

The only advantage generic names for the "optional" and "post" milestones would be that renaming them isn't necessary anymore. Given how rarely that happens, I consider that a non-issue. I'd rather have the (IMO) more descriptive names which include the version number, but that's of course more of a cosmetic issue and a matter of personal preference.

The only way to avoid the reassigning of issues/PRs after a release I see would be to give up the "post" milestone.
We need a milestone for blocking issues and required features of the next release version. We could name it "vX.Y.Z".

We need a milestone for non-blocking issues, implemented but non-required features and upcoming requested features. We could name it "optional"

We need a milestone for long term works in progress (WIP) and wished for feature requests. We could name it "wishlist.

If we used milestone names like "vX.Y.Z", "optional" and "wishlist, then after release a new milestone named "vX.Y+1.Z" would be created to which a single feature request is moved from "optional. Otherwise nothing would change.
I'm a bit confused... except the last step, all this is practically the same as the current scheme, just different names for the milestones.

And I don't get that last step: what single feature request are you referring to here? Issues/PRs assigned to "optional" need to be reassigned to "vX.Y.Z" if we decide to promote something from being optional to being required for the next release, which is certainly not restricted to one item, and does not only happen right after a release. Also, this does not cover that items need to be moved from the "wishlist"/"post" milestone to "optional"...?

Sorry, it's not that I'm not open to revising my workflow here, you just need to have a bit more patience with me until I get what you mean. ;)

LGM-Doyle
Programmer
Posts: 219
Joined: Mon Feb 29, 2016 8:37 pm

Re: 0.4.8 roadmap

#3 Post by LGM-Doyle » Sun Dec 10, 2017 8:49 pm

Vezzra wrote:What do you mean by "most other re-labelings"?
I meant that changing an issue's label changes its timestamp.
Vezzra wrote:renaming of a milestone (which should not change the timestamps)
I expect that renaming the milestone will change the timestamp. If renaming the milestone does not change the timestamp, then all of this discussion is moot.
Vezzra wrote:"post" = should not go in.
This I misunderstood. I assumed that if new contributor showed up with a fully functional Battle Simulator, before we started test a release candidate, we would help them merge it rather than saying, "Please wait a month or two". That is why I called it the third milestone wishlist.
Vezzra wrote:Given how rarely that happens, I consider that a non-issue.
It is because it is rare that it is an issue. As time progresses we will accumulate issues. In a year we might have 1000+ unresolved minor issues/feature requests. With the current system, after a release renaming the optional Vx.y.z milestone will timestamp all of the issues. An issue that has had no other activity in two years and the latest feature request both look the same. If a new dev is looking for something to implement/fix, it would be better if they selected from a newer issue without trolling through any cruft. With the suggested system, a future maintainer can cull old issues without having to open every issue and see if there was some activity other than the milestone change.
I'd rather have the (IMO) more descriptive names which include the version number ... a matter of personal preference
You are doing the work, so it is your preference that should get double weight.
Vezzra wrote:all this is practically the same as the current scheme, just different names for the milestones
Correct. The different names (without version numbers) for wishlist and optional means that they have the same purpose regardless of the current target version.
Vezzra wrote:And I don't get that last step: what single feature request are you referring to here?
This was implying that the new milestone would start with only the single core feature being transferred from wishlist or optional. It was also a too oblique reference to the absence of an influence issue to be transferred. :wink:

It was not meant to imply that other items could not move as well, but any move would be significant and indicate a change in status (and timestamp) of that particular issue.

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

Re: 0.4.8 roadmap

#4 Post by Vezzra » Mon Dec 18, 2017 3:51 pm

LGM-Doyle wrote:I meant that changing an issue's label changes its timestamp.
Ah yes, sure, right. That's why I discarded any ideas trying to achieve a mandatory/optional/postpone categorization with labels - wouldn't have solved anything.
I expect that renaming the milestone will change the timestamp. If renaming the milestone does not change the timestamp, then all of this discussion is moot.
Oh... ok, of course. If renaming a milestone changes the timestamp of issues/PRs assigned to it, forget everything I said. My reasoning is based on the assumption that milestone renaming does not change timestamps.
I assumed that if new contributor showed up with a fully functional Battle Simulator, before we started test a release candidate, we would help them merge it rather than saying, "Please wait a month or two". That is why I called it the third milestone wishlist.
Ok, I understand. I'd handle cases like this as "optional" too, something that can go in, but isn't required. Unless we decide that incorporating the fully functional battle simulator into master will postpone the release too much, in which case the battle simulator would be assigned to the "post" milestone.
I'd rather have the (IMO) more descriptive names which include the version number ... a matter of personal preference
You are doing the work, so it is your preference that should get double weight.
Well, not having all the issues/PRs their timestamps reset (which, as you pointed out, isn't exactly helpful when trying to work through the issues/PR list) certainly takes precedence over my personal tastes. ;)
This was implying that the new milestone would start with only the single core feature being transferred from wishlist or optional. It was also a too oblique reference to the absence of an influence issue to be transferred. :wink:

It was not meant to imply that other items could not move as well, but any move would be significant and indicate a change in status (and timestamp) of that particular issue.
Ah yes, that makes sense.

Well, we can adjust the workflow according to your suggestion after the release (won't be of any use before I guess): create a milestone "vX.Y.Z" (or "next release" if the version number of the next release hasn't been decided yet) and move all issues/PRs that are mandatory for the next release to it. Then have two milestones, "optional" and "postponed", which won't change with releases. By default issues and PRs are assigned to "optional", unless they are deemed mandatory of course. Then move issues/PRs between "optional" and "vX.Y.Z"/"next release" as required. Once we get close enough to a release that having to postpone issues/PRs becomes necessary, move the respective issues/PRs to "postponed". Issues/PRs that are assigned to "optional" and get resolved/merged have to be moved to "vX.Y.Z"/"next milestone" with this new scheme of course.

Once a release is out:
  • Close the corresponding "vX.Y.Z" milestone.
  • Create a new "vX.Y.Z+1"/"next milestone" issue.
  • Either create new issues/PRs for the essential/mandatory features for the next release and assign them to "v.X.Y.Z+1"/"next release", or, if they already exists, move them to "v.X.Y.Z+1"/"next release". Those already existing issues/PRs can come from both "optional" or "postponed" of course.
  • Move everything left in "postponed" back to "optional".
Sounds reasonable? Any comments, anyone?

User avatar
Dilvish
AI Lead, Programmer
Posts: 4720
Joined: Sat Sep 22, 2012 6:25 pm

Re: 0.4.8 roadmap

#5 Post by Dilvish » Sat Dec 23, 2017 6:03 pm

Hi, guys, I am freed up a bit more for the next week, will try to catch up on things and make some progress on the issues I was working on.
Move everything left in "postponed" back to "optional".
Wouldn't that reset the timestamps, and actually make all those previously postponed (presumably because of being lower priority) items appear newer (and therefore relatively higher priority) than the items that had been labeled "optional" all along?

If I am understanding that correctly, it seems to me that it is best to stick with a pair of labels (for the non version-mandatory items) that essentially connote "high-priority optional" and "low-priority optional", and that it would be pretty typical that those labels would not change over the life of the item (though of course promotions/demotions between those two or to/from version-mandatory could be possible). Using the previously proposed "optional" and "wishlist" labels for that purpose sounds fine to me.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

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

Re: Managing Github Milestones

#6 Post by Vezzra » Sat Sep 01, 2018 7:03 pm

Ok, 0.4.8 is out, time to return to this discussion (which I split from the 0.4.8 roadmap thread).

When I went ahead with the rearranging/reassinging of milestones after 0.4.8 was done, I realized that my last idea to just rename the "0.4.8 (optional)" to "optional" and just keep that in future without further renaming won't work. The problem with that approach is that you wouldn't be able to tell to which release all the issues and PRs assigned to "optional" that have been closed/merged belonged, so I discarded this idea.

So, for this time, I decided to reassign all the still open issues/PRs of the "0.4.8 (optional)" milestone to the "post 0.4.8" milestone, renamed the latter to "next release" and closed both 0.4.8 release milestones. Which will enable us to easily determine which issues/PRs have been resolved/merged in the 0.4.8 release cycle (should the need ever arise).

That leaves the question how to handle things in the future. As the default ordering of issues/PRs on the github tracker isn't by latest update timestamp, but apparently something depending on original creation time, I didn't notice significant changes after doing the mass reassigning to the "post 0.4.8" milestone. So I wonder if the issue LGM-Doyle raised really is that much of a big deal (in that case a workflow with mass milestone reassignments wouldn't be a problem). However, if you prefer to sort issues/PRs by update timestamp, then yes, mass reassigning issues/PRs indeed does reset their update timestamps and consequently completely messes up the sorting.

In that case we need to come up with something that keeps mass milestone reassignments to a minimum. The only way I see to achieve that is to not use "optional" and "post" milestones at all. I propose the following:

Only have 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, rename it to the version number (using the "vX.Y.Z" scheme). Of the still open issues/PRs only those mandatory 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. As I see no real need to distinguish between issues/PRs that don't need a milstone (like those infrastructure issues/PRs), are optional, or where a decision about if they are mandatory or not hasn't been made yet, that should be good enough. And even if it turns out that it e.g. would be good to tag issues/PRs where a decision about mandatory or not is pending, I think that can be easily solved with proper labels.

However, what happens when an "optional" issue/PR (which won't have a milstone assigned yet) gets closed/merged? To preserve the information which release it belongs to, it needs to get a milestone assigned at that point. In case the release branch for the new release hasn't been created yet, it can simply be 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 now of course).

Once the release is out, close the release milestone, rename the "post release" milestone to "next release" so it becomes the new release milestone, which already contains all closed/merged issues/PRs that didn't get into the last release, but will of course be in the next release.

The main loss would be the "post vX.Y.Z" milestone marking issues/PRs which should not go into the upcoming release, but I think that info can be derived sufficiently reliably from other "properties" of the corresponding issues/PRs: prior to the creation of a release branch those are usually quite rare, so it's probably not really necessary to tag them in any way. After the creation of a release branch the only issues/PRs that can get into the release are the ones already assigned to the release milestone (because they are mandatory for the release), and the only other issues/PRs that can get into the release are bugfixes. So anything that doesn't meet these criterias are post release.

That should prevent all mass reassigning of milestones, keep the info which release closed issues/PRs belong to, and still provide us with everything we need for a proper workflow.

Comments, opinions, objections, improvements, other/better ideas, etc.?

o01eg
Space Kraken
Posts: 175
Joined: Sat Dec 10, 2011 5:46 am

Re: Managing Github Milestones

#7 Post by o01eg » Sat Sep 01, 2018 7:30 pm

What about fix release v0.4.8.X? Some issues are still present in 0.4.8 and could be solved without breaking compatibility.
Gentoo Linux x64, gcc-7.3, boost-1.65.0
Ubuntu Server 18.04 x64, gcc-7.3, boost-1.65.1
Welcome to multiplayer server at freeorion-test.dedyn.io.Version 0.4.8
Donates are welcome: BTC:14XLekD9ifwqLtZX4iteepvbLQNYVG87zK

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

Re: Managing Github Milestones

#8 Post by Vezzra » Sun Sep 02, 2018 10:05 am

o01eg wrote:
Sat Sep 01, 2018 7:30 pm
What about fix release v0.4.8.X?
If we decide to make a 0.4.8.x bugfix release (which isn't unlikely because the current release cycle probably will be a big one), this could be done by creating a "v0.4.8.X" milestone and assign all issues/PRs to it that are going to be dealt with in/merged into the 0.4.8 release branch.

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

Re: Managing Github Milestones

#9 Post by Vezzra » Fri Sep 14, 2018 11:03 am

Bump? Geoff, Dilvish? Are the changes to milestone handling I proposed ok with you, or do you have any objections, other ideas...?

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

Re: Managing Github Milestones

#10 Post by Geoff the Medio » Fri Sep 14, 2018 5:34 pm

I don't really have much opinion on GitHub milestones, or time right now to read over the length of text you posted... But if you think something should be changed, it's probably fine.

User avatar
Dilvish
AI Lead, Programmer
Posts: 4720
Joined: Sat Sep 22, 2012 6:25 pm

Re: Managing Github Milestones

#11 Post by Dilvish » Fri Sep 14, 2018 6:52 pm

Let me confirm some points of my understanding--
- the main motivation for a change is that the new-release-number-mass-milestone-reassignment is both a headache (at least as currently done manually) and obliterates last-update timestamp info which is otherwise very useful for sorting (and like LGM-Doyle, I do find that sorting helpful)

So to avoid that the current proposal is that we'd have
- the only open PRs/issues that would bear a milestone would be those considered mandatory for the next release (i.e. the one we are currently working on at that time).
- the great majority of open PRs, and perhaps a majority of open issues, would therefor probably not bear an explicit milestone (but would get one when merged/closed)
- the cost/loss is the explicit distinction between "0.x.y (optional)" and "post 0.x.y", or what would have been in one alternate "optional" vs "wishlist"

That all seems acceptable to me, but it seems to me that a bit more got thrown out in that last bullet point than was really needed to be thrown out.

What seems to be to have been clarified as fairly definite requirements for the milestone framework are that the only version-specific milestone would be for mandatory or merged/closed PRs/issues, and then any other milestones would need to be generic (and noting that the absence of an assigned milestone seems equivalent to just a type of generic milestone), and that an Issue/PR with a generic milestone would get assigned a version-specific milestone when it was either merged/closed or else was upgraded to mandatory status.

Furthermore, Vezzra rightly concluded that "optional" | "post" does not really work as a pair of generic milestones since the use of "post" would require mass updates. I think that really means simply that "post" is not really a generic milestone, it is an implicitly version-specific milestone, and the rejection of it doesn't mean we need to reject the whole idea of generic milestones.

I think I rather like being able to distinguish medium/high priority optional from low priority optional; the previously proposed "optional" and "wishlist" would seem to represent those OK and would be better than nothing. So the only distinction between this and Vezzra's latest proposal would be that instead of a single tier of generic optional-type PRs/issues (blank milestone) using that generic milstone until they were changed when either upgraded to mandatory or closed/merged, we could instead have two tiers of generic optional milestone (such as "optional" and "wishlist"), which likewise would only be changed when either upgraded or closed/merged. Am I overlooking some complication?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

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

Re: Managing Github Milestones

#12 Post by Vezzra » Sun Sep 16, 2018 1:26 pm

Dilvish wrote:
Fri Sep 14, 2018 6:52 pm
Let me confirm some points of my understanding--
- the main motivation for a change is that the new-release-number-mass-milestone-reassignment is both a headache (at least as currently done manually) and obliterates last-update timestamp info which is otherwise very useful for sorting (and like LGM-Doyle, I do find that sorting helpful)
The latter being the main issue here, the former is more of a nuisance than an issue, and not having to deal with it is just a nice side effect. Aside from that, yes, correct.
So to avoid that the current proposal is that we'd have
- the only open PRs/issues that would bear a milestone would be those considered mandatory for the next release (i.e. the one we are currently working on at that time).
- the great majority of open PRs, and perhaps a majority of open issues, would therefor probably not bear an explicit milestone (but would get one when merged/closed)
- the cost/loss is the explicit distinction between "0.x.y (optional)" and "post 0.x.y", or what would have been in one alternate "optional" vs "wishlist"
Correct.
I think I rather like being able to distinguish medium/high priority optional from low priority optional; the previously proposed "optional" and "wishlist" would seem to represent those OK and would be better than nothing. So the only distinction between this and Vezzra's latest proposal would be that instead of a single tier of generic optional-type PRs/issues (blank milestone) using that generic milstone until they were changed when either upgraded to mandatory or closed/merged, we could instead have two tiers of generic optional milestone (such as "optional" and "wishlist"), which likewise would only be changed when either upgraded or closed/merged. Am I overlooking some complication?
Nope, you don't overlook anything, I see no reason why this shouldn't work just fine.

That said, if we want this kind of "priority" setting, personally I'd prefer to do that with labels. First, such "priorities" aren't really milestones semantically (IMO), and second, having those as lables allows for more flexibility: we can then have different priorities within each milestone setting, which sounds useful to me. I'd introduce another "group" of labels ("priority:*" in addition to the "category:*", "component:*" and "status:*" groups), and have either "priority:high", "priority:normal", "priority:low", or "priority:medium" instead of normal, or no "priority:medium/normal" label and no "priority:*" label meaning default normal/medium priority. Or something like that.

However, what neither of these approaches (be it priority labels or generic "optional"/"wishlist" milestones) covers is the purpose of the "post" label. That isn't really meant as a marker for "low priority" or something on a wishlist (which might or might not be implemented in the distant future), but to mark issues/PRs that should be postponed after the upcoming release, mainly for two reasons: to help redirect/focus precious dev time to things relevant for the upcoming release, and to prevent things to go into master that might delay the upcoming release (because of the potential issues they might introduce). That would still be lost, even with generic priority milestones/labels.

User avatar
Dilvish
AI Lead, Programmer
Posts: 4720
Joined: Sat Sep 22, 2012 6:25 pm

Re: Managing Github Milestones

#13 Post by Dilvish » Sun Sep 16, 2018 7:02 pm

Vezzra wrote:
Sun Sep 16, 2018 1:26 pm
...That said, if we want this kind of "priority" setting, personally I'd prefer to do that with labels....and have either "priority:high", "priority:normal", "priority:low", or "priority:medium..."
Your reasoning and proposal sound good to me.
However, what neither of these approaches (be it priority labels or generic "optional"/"wishlist" milestones) covers is the purpose of the "post" label... to mark issues/PRs that should be postponed after the upcoming release, mainly for two reasons: to help redirect/focus precious dev time to things relevant for the upcoming release, and to prevent things to go into master that might delay the upcoming release (because of the potential issues they might introduce). That would still be lost, even with generic priority milestones/labels.
Although the generic priorities perhaps can't handle that quite as clearly as the explicit "post" milestone did, I think they could still accommodate that general handling just fine-- as we approach making a new release branch, at some point prior to actually making the branch we'd announce a hiatus on merging any Low priority PRs.

With a bit of work we could even enforce such a rule during that phase of the release process by making master a Protected branch, with the protection level being that all CI checks must pass, and (temporarily, during that phase) adding/enabling a PR label check in one of the CI builds.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

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

Re: Managing Github Milestones

#14 Post by Vezzra » Thu Sep 20, 2018 12:07 pm

Dilvish wrote:
Sun Sep 16, 2018 7:02 pm
Although the generic priorities perhaps can't handle that quite as clearly as the explicit "post" milestone did, I think they could still accommodate that general handling just fine-- as we approach making a new release branch, at some point prior to actually making the branch we'd announce a hiatus on merging any Low priority PRs.
I guess we can replicate the former "post" milestone at least to a certain degree/sufficiently well with that approach.
With a bit of work we could even enforce such a rule during that phase of the release process by making master a Protected branch, with the protection level being that all CI checks must pass, and (temporarily, during that phase) adding/enabling a PR label check in one of the CI builds.
Yes, sounds interesting.

Post Reply