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

Comments

Projects
None yet
9 participants
@bradfitz
Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

commented May 5, 2017

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Contributor

commented May 5, 2017

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

@spf13

This comment has been minimized.

Copy link
Contributor

commented May 5, 2017

@campoy

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member Author

commented May 5, 2017

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

@leitzler

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Member

commented May 8, 2017

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

@bradfitz

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2017

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

Alternatively, "early-in-cycle".

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2017

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

@bradfitz

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2017

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

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Jun 13, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Dec 13, 2017

@andybons, anything remain here?

@andybons

This comment has been minimized.

Copy link
Member

commented Dec 13, 2017

Nothing that I see in our tooling, no.

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Dec 13, 2017

Thanks, closing.

@bradfitz bradfitz closed this 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.
You can’t perform that action at this time.