Page MenuHomePhabricator

Establish suitable short-term replacement for important code review tags
Closed, DeclinedPublic

Description

Right now this document has a section titled "Annotations":
https://www.mediawiki.org/wiki/Git/Code_review/guide#Annotations

We have several tags ("scaptrap", "schema", "fixme", and the tags used for marking things for backporting, for example) that don't have equivalent workflow replacements in the brave new world of Git and Gerrit. At a minimum, we need to update the guide, but more importantly, we need to have replacement workflows that don't involve hoping the Gerrit devs get around to implementing tags.

(permalink to annotations: https://www.mediawiki.org/w/index.php?title=Git/Code_review/guide&oldid=559641#Annotations )


Version: unspecified
Severity: normal

Details

Reference
bz38239

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:00 AM
bzimport added a project: Gerrit.
bzimport set Reference to bz38239.
bzimport added a subscriber: Unknown Object (MLST).

Chad: Any update on this work? I would love to start using this to track backports for wmf deploys (and I'm sure Mark H would love it for managing some of his release work as well).

Anything blocking you here other than time?

It's going to be a while before Gerrit supports the features that we need to make this work. Let's come up with a non-technical workaround for this problem. Greg, can you work with the team on some sort of process for this?

Update on this:

Some things I've been doing:

  1. communicating more frequently with the features teams to get an idea of risk/other needed dependencies for their deploys.
  1. A partial solution is the "Next WMF Deploy" tracking bug (bug 38865). But that is only useful for things that have an associated bug (and it needs the person to be able to read the bug for context, which can be noisy).
  1. still wishing we had tags in Gerrit.... https://code.google.com/p/gerrit/issues/detail?id=287

With tags in Gerrit, we could have git-deploy/Sartoris/Trebuchet display such information to the deployer (with confirmation that they looked at them) when such scaptrap/highrisk changes are getting ready to be deployed.

Unassigning from self for now, will add to DevOps backlog (due to the use-case with git-deploy).

(In reply to Greg Grossmeier from comment #3)

Unassigning from self for now, will add to DevOps backlog (due to the
use-case with git-deploy).

Still high priority on the list?

This should just be a requirement for the next thing we switch to (since the momentum behind getting it in gerrit is mostly gone).

Fabricator almost has this with their "tokens" thing.

Flagging seems user specific.

greg lowered the priority of this task from Medium to Low.Sep 10 2015, 11:05 PM
Nemo_bis claimed this task.

Three years passed, so the "short-term" is clearly declined. Upstream already provides the long-term fix (T37534).