Remove --milestone to force engineers to double-check with TPMs for branch number.

Remove --milestone to force engineers to double-check with TPMs for branch number.

BUG=304943
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=227348

[Marc-Antoine Ruel (Google), 2013-10-07 21:18:36]

rubberstamp lgtm

[laforge, 2013-10-07 21:21:52]

lgtm

[commit-bot: I haz the power, 2013-10-07 21:34:41]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dbeam@chromium.org/26280004/1

[commit-bot: I haz the power, 2013-10-07 21:36:20]

Change committed as 227348

[ojan, 2013-10-30 21:31:39]

Can http://www.chromium.org/developers/how-tos/drover be updated with the new
best practice? Should I really be asking a TPM what the branch number is?

[Dan Beam, 2013-10-30 21:32:32]

On 2013/10/30 21:31:39, ojan wrote:
> Can http://www.chromium.org/developers/how-tos/drover be updated with the new
> best practice? Should I really be asking a TPM what the branch number is?

apparently kareng@ thinks so

[jsbell, 2013-10-30 21:36:46]

On 2013/10/30 21:32:32, Dan Beam wrote:
> On 2013/10/30 21:31:39, ojan wrote:
> > Can http://www.chromium.org/developers/how-tos/drover be updated with the
new
> > best practice? Should I really be asking a TPM what the branch number is?
> 
> apparently kareng@ thinks so

I did a quick edit to the page, but please feel free to elaborate/clarify/etc.

[laforge, 2013-10-30 21:47:04]

On 2013/10/30 21:32:32, Dan Beam wrote:
> On 2013/10/30 21:31:39, ojan wrote:
> > Can http://www.chromium.org/developers/how-tos/drover be updated with the
new
> > best practice? Should I really be asking a TPM what the branch number is?
> 
> apparently kareng@ thinks so

The problem w/ the implementation was that it would report the wrong branch, if
there were any published releases with the same major version number (e.g. 
ChromeOS didn't update their dev channel, and had last week's 31, or we didn't
increment the major version on trunk and Canary was at Major.0.Branch+1.0,
etc...).  This has been a significant problem, immediately post-branch point,
when merge requests are at their peak (i.e. pretty much the worst time for that
info to be bad).

The other problem was the it would report on branches that we didn't want
developers to touch (i.e. our so-called mini-branches that we use to cherry pick
specific fixes), developers were getting confused and merging to all of them...
which was a larger source of confusion.

Generally speaking, it's hard to programmatically/correctly determine which
branch represents the source of truth for a milestone, which force the code to
be generalized (reporting all possible branches) and was in turn causing merges
to go to incorrect locations.  

FWIW, all the merge-approval notifications that developers receive contain the
branch that we want them to merge to.  All that said... it actually might be
worthwhile to re-implement the same logic that our merge-approval bot uses to
determine the branch of truth... if one were inclined to bring this feature
back.