Go: x/build: stop using Early and Maybe milestones, update tools to early-in-cycle, release-blocker

[bradfitz]

Currently Go use 3 different GitHub Milestones for each Go release.

• Go1.9Early
• Go1.9
• Go1.9Maybe

@spf13, @campoy and I would like to eliminate the "Early" and "Maybe" milestones and only keep the "Go1.9" style one. The information conveyed by the "Early" and "Maybe" parts will be converted into new labels (names TBD).

The meaning of the current milestones is not widely known by people outside the few people who use them:

• Go1.9 - "This could or should be done in Go 1.9"
• Go1.9Early - "This could or should be done into Go 1.9 but if it does--because it's kinda big or risky--it needs to be submitted early in the 3 month merge window, like within the first month so we can find any problems earlier."
• Go1.9Maybe - "This could be fixed in Go 1.9, but we we won't hold the release up for it."

Note that "Early" doesn't mean high priority and is not mutually exclusive with "Maybe". We've had a number of bugs kicked along from e.g. Go1.8Early to Go1.9Early to Go1.10Early. It only means it's must land early if it does.

This bug is about figuring out the label names.

The obvious choices are for label names are "Early" and "Maybe", but given people's confusion in the past, and because adding "Maybe" to somebody's bug feels and looks a big rude, we thought we'd open up the discussion for alternative names.

Some possibilities for Maybe:

• Maybe (rude?)
• Not-Release-Blocker
• Not-Blocker
• Priority-Low (leaves open possibility of using others in the future? also rude?)
• ... ?

For Early:

• Early
• Early-Only
• Not-11th-Hour (this is horrible, but says what we're trying to convey)

Ideas welcome. (But note that it's an explicit non-goal of this bug to revamp all our labels right now. Let's limit proposals to just these two, but you can keep future labels in mind.)

[josharian]

Proposal:

• 1.9maybe: no label
• 1.9: label "Blocks-Release"
• 1.9early: label "Not-During-Freeze"

The connotations here probably mean there'd be a lot fewer "regular" (Blocks-Release) issues, since Blocks-Release sounds intimidating, but that probably reflects reality better anyway.

[bradfitz]

Could work, but early doesn't mean "not during freeze". It means first month. Not even first three months. AIUI.

[josharian]

I dunno. No one says labels need to be short. "High-Risk"? "First-Month-Of-Cycle"? "Needs-Soak"? "Early-Freeze"? Blah.

[spf13]

I like the approach of marking things the release needs vs things that can
be bumped.

Maybe "first-month". It's much more clear the the alternatives IMO.

"release-critical" or "release-blocker" both sound good to me.

I'll see what other projects use. Perhaps there's a perfect label out
there.

On Fri, May 5, 2017 at 11:48 AM Josh Bleecher Snyder <
[email protected]> wrote:

I dunno. No one says labels need to be short. "High-Risk"?
"First-Month-Of-Cycle"? "Needs-Soak"? "Early-Freeze"? Blah.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/20252#issuecomment-299501417, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAKlZAAHl52Ob29mNIRqOuQl0wjFlizbks5r20TggaJpZM4NRe94
.

[campoy]

I like the fact that no label implies maybe, so by default bugs do not block release until proven.

For early, my favorite is "early-only" or something like "first-weeks"

[bradfitz]

"early-only" and "release-blocker" are sounding good.

[leitzler]

I do like "high-risk" for early things. Then the label doesn't have to include a specific time window, and is kind of more clear than "first-weeks"/"early-only".

[bradfitz]

"early-only" doesn't necessarily imply high risk, though. It often means that it's a massive refactoring and doing it even 2 months after the dev window opens means that you would cause rebase hell for other people's in-flight changes. So certain large changes (even trivial low-risk changes) we pre-schedule to be landed within the first week of the tree opening.

So I'd like to avoid talking about risk.

[rasky]

Why not something that refers to the size of the change? Like "huge-change", "massive", "big", "large".

[bradfitz]

@rasky, because a) those are subjective and would need to be defined, and b) that's still not what "early" means today. It's not about size.

[bradfitz]

@spf13, @rsc, @ianlancetaylor, thoughts on new labels "early-only" and "release-blocker"?

Alternatively, "early-in-cycle".

[ianlancetaylor]

Personally I like early-in-cycle and release-blocker. Although given our current label syntax perhaps it should be EarlyInCycle and ReleaseBlocker.

[bradfitz]

@ianlancetaylor, @spf13 tells me that the Github world conventionally uses the "foo-bar" style instead of "FooBar" and we're Doing It Weird. Steve had a doc proposing we change to the normal style.

I'm neutral on whether we make that change but if we're going to do it, I'd slightly prefer starting these labels in the lowercase style rather than having to convert them later also.

Alternatively, we go all lowercase first.

@spf13, did you still want to do that? Do others feel strongly either way?

[ianlancetaylor]

Oh, OK, sure, let's do the conventional thing.

[bradfitz]

Okay, I've created the early-in-cycle and release-blocker labels and made this issue use it.

We'll switch our various dashboards & tooling to use these new labels during the Go 1.10 cycle.

[bradfitz]

@andybons, anything remain here?

[andybons]

Nothing that I see in our tooling, no.

[bradfitz]

Thanks, closing.