Here is a summary about the relevant comments so far:
PR#2043 proposes the following changes to the description of the "component:infrastructure" label of our github tracker:
Code: Select all
diff --git a/.github/labels.md b/.github/labels.md
index 9195dbb1a6..2736190e3f 100644
--- a/.github/labels.md
+++ b/.github/labels.md
@@ -112,7 +112,13 @@ content of the PR may require extensive gameplay balance testing.
The Issue/PR deals with non-game related infrastructure that aids development.
For example this includes issues with the project homepage, used external
-services like continuous integration or hosting of release binaries.
+services like continuous integration, hosting of release binaries, tools for
+checking code style, etc.
+
+Infrastructure Issues/PRs usually do *not* contain any changes to the actual
+codebase (which means that Issues/PRs which *do* contain changes to the codebase
+should not be tagged as infrastructure). For this reason infrastructure
+Issues/PRs also don't get assigned milestones (as they don't affect the builds).
#### Label `component:internal`
Cjkjvfnby suggested to add part of my comment to the description of the "component:infrastructure" label, which lead to me opening PR#2043, where Dilvish commented as follows:Vezzra wrote:Just a brief note on the "infrastructure" and "no milestone" thing: I noticed a couple of PRs that have been tagged as "infrastructure", of which at least some seem to be kind of edge cases.
"Infrastructure" usually refers to things like e.g. the Travis and AppVeyor CI, tools which check code style etc. It does not apply e.g. to logging code or any changes to the actual codebase (be it C++ or Python), IMO.
That's why "infrastructure" issues/PRs don't get assigned milestones - they don't affect the codebase, and therefore the builds, hence it doesn't really matter when such changes go in, hence no milestone.
On the other hand, everything that does change the the actual codebase must get a milestone assigned (because when such changes get in does affect the builds). Let this be your guideline when you decide on what to tag as "infrastructure" and assigning milestones.
I think that should cover the most important statements so far. Please continue the discussion here.Dilvish wrote:Hmm, it looks to me like the second paragraph partly reiterates the first while trying, and at least partially succeeding, to clarify the first, and includes some new info (about the no milestones). The second paragraph could easily be incorporated into the first, preference between one or two paragraphs seems like a style choice but also would be partly dependent on just how much of this winds up added.
Right now this second paragraph only partly succeeds in clarifying the first because it is partly self contradictory. The main clause of the first sentence states that infrastructure PRs "_usually_" do not contain any changes to actual code, which implies that sometimes they can. But the parenthetical says they categorically should not. If the possibility of exceptions is truly contemplated, but only extremely rarely, then I would suggest something along the lines ofIf you intend it to be a firm rule that there truly never be actual code changes in an infrastructure PR, then the "Absent exceptional circumstances" would be tossed and "should not" changed to "cannot". But just consider then what if there are some code changes that go along with some infrastructure change, you could always simply break them out as a separate PR, but then the "code" PR would get a milestone while the "infrastructure" PR it goes hand-in-hand with would not-- seems like a strange/wrong outcome. Which segues to my next paragraph...Code: Select all
Absent exceptional circumstances, Infrastructure Issues/PRs should not contain any changes to the actual codebase.
Regarding the sentence about milestones, well, if "no milestones for infrastructure" stays the policy then it certainly should be so stated in this/these paragraph(s) somewhere. I think I was rather inactive during the period when these labels and such policy was worked out, but I'm not finding anything here to clarify it and I feel compelled to note both that it doesn't really make a lot of sense to me, and when searching around about milestone policies I have not yet found any support for it. What is wrong with the idea that we might want to have certain infrastructure/testing in place for 0.4.8 to improve the code-style and/or reliability of that release, in which case related infrastructure PRs should bear that milestone?
I certainly don't see any support for the "For this reason" phrase of the milestone sentence.