1167630 - Support creating multiple bugs by specifying non-numeric bug syntax

Status: RESOLVED INVALID

(MozReview Graveyard :: General, defect, P3)

Description

[Gregory Szorc [:gps]]

Filing this to capture something we should implement a few months from now when auto bug filing on push is implemented. (This is partially inspired by bsmedberg's complaint yesterday that managing MozReview requests when you have a complex "stack" of commits is hard.)

Scenario:

A developer is working on a large feature. As they are creating their commits, they stumble across an unrelated area in need of improvement. This area is completely separate from what they are working on. It deserves to be its own bug and its own mini feature.

Problem:

How do we communicate to MozReview that the mini-series is separate from the main line of commits?

Many will say that the proper way to do this is to create separate feature branches / DAG heads in your VCS and to push each separately to MozReview to create multiple series. That works. But it is more effort for developers.

Alternatively, you can tell MozReview which revisions to push. Specify a range via `hg push -r X::Y` and only the commits in that range will be pushed. This works, but again, it is more effort for developers, as they need to manually type commit ranges into commits.

Neither solution "just works" and creates more work for developers.

Proposed Solution:

Before I introduce the proposed solution, keep in mind that in a future world we will support auto-filing bugs on push. We'll use the bugzilla metadata from moz.build files (and potentially other sources) to determine the most appropriate bug component for a set of files that changed. During push, a new bug will be filed automatically, commit messages will be rewritten to include the bug number, and any children commits will be automatically rebased against the rewritten commits.

Also, we assume we'll eventually relax the one bug per series requirement. That implementation detail unfairly limits workflows and pretty much forces people to adopt feature branches or manual commit / push management. We want `hg push` to "just work."

Here's my idea.

When developers are creating commits and they know they are starting a new mini-series that deserves to be its own bug, they will employ a non-numeric bug syntax in their commit messages to denote different series. e.g.

  Bug a - Main feature commit 1
  Bug a - Main feature commit 2
  Bug b - Unrelated work
  Bug c - More unrelated work
  Bug a - Main feature commit 3

When we push these commits, we'll parse the non-numeric bug "number" and treat it as a grouping identifier. After the push, we'll have:

  Bug 1 - Main feature commit 1
  Bug 1 - Main feature commit 2
  Bug 2 - Unrelated work
  Bug 3 - More unrelated work
  Bug 1 - Main feature commit 3

I think this a pretty ideal because developers merely need to include a grouping identifier when they make the commit locally. They simply `hg push` and things "just work."

Comment 1

[BMO Automation]

MozReview is now obsolete. Please use Phabricator instead. Closing this bug.