Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bradfitz opened this issue May 5, 2017 · 18 comments
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@bradfitz
Copy link
Contributor

bradfitz commented May 5, 2017

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.)

@bradfitz bradfitz added this to the Unreleased milestone May 5, 2017
@bradfitz bradfitz self-assigned this May 5, 2017
@josharian
Copy link
Contributor

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
Copy link
Contributor Author

bradfitz commented May 5, 2017

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

@josharian
Copy link
Contributor

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

@spf13
Copy link
Contributor

spf13 commented May 5, 2017 via email

@campoy
Copy link
Contributor

campoy commented May 5, 2017

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
Copy link
Contributor Author

bradfitz commented May 5, 2017

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

@leitzler
Copy link
Contributor

leitzler commented May 6, 2017

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
Copy link
Contributor Author

bradfitz commented May 6, 2017

"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
Copy link
Member

rasky commented May 8, 2017

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

@bradfitz
Copy link
Contributor Author

bradfitz commented May 8, 2017

@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
Copy link
Contributor Author

bradfitz commented Jun 6, 2017

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

Alternatively, "early-in-cycle".

@ianlancetaylor
Copy link
Contributor

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

@bradfitz
Copy link
Contributor Author

bradfitz commented Jun 6, 2017

@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
Copy link
Contributor

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

@bradfitz bradfitz added early-in-cycle A change that should be done early in the 3 month dev cycle. NeedsFix The path to resolution is known, but the work has not been done. and removed help wanted Thinking labels Jun 13, 2017
@bradfitz bradfitz modified the milestones: Go1.10, Unreleased Jun 13, 2017
@bradfitz
Copy link
Contributor Author

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 bradfitz changed the title github: stop using Early and Maybe milestones, decide label names x/build: stop using Early and Maybe milestones, update tools to early-in-cycle, release-blocker Jun 13, 2017
@bradfitz bradfitz removed their assignment Jun 13, 2017
@bradfitz
Copy link
Contributor Author

@andybons, anything remain here?

@andybons
Copy link
Member

Nothing that I see in our tooling, no.

@bradfitz
Copy link
Contributor Author

Thanks, closing.

@bradfitz bradfitz closed this as completed Jan 4, 2018
@golang golang locked and limited conversation to collaborators Jan 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

9 participants