Include range summary when rolling into chromium.

Include range summary when rolling into chromium.

BUG=chromium:457022
TBR=tandrii@chromium.org
NOTRY=true
LOG=n

TEST=./script_test.py

Committed: https://crrev.com/15c269b760fdddc1d95e8e15dca6356f3854acb3
Cr-Commit-Position: refs/heads/master@{#26659}

[Michael Achenbach, 2015-02-12 10:28:52]

machenbach@chromium.org changed reviewers:
+ tandrii@chromium.org

[Michael Achenbach, 2015-02-12 10:38:55]

PTAL

https://codereview.chromium.org/918953003/diff/20001/tools/release/common_inc...
File tools/release/common_includes.py (left):

https://codereview.chromium.org/918953003/diff/20001/tools/release/common_inc...
tools/release/common_includes.py:656: return latest_hash
Just returning here wouldn't be correct with the new branching strategy. It
would include the version file change commit on the branch. For calculating the
change log that makes no difference, but for the summary of rolled changes it is
cleaner to not show it in my opinion.

https://codereview.chromium.org/918953003/diff/20001/tools/release/test_scrip...
File tools/release/test_scripts.py (left):

https://codereview.chromium.org/918953003/diff/20001/tools/release/test_scrip...
tools/release/test_scripts.py:1018: Cmd("git log -1 --format=%H 3.22.4",
"push_hash\n"),
That under the tag 3.22.4 is the version 3.22.5 was an error in the test.

[tandrii(chromium), 2015-02-13 22:29:08]

lgtm

https://codereview.chromium.org/918953003/diff/20001/tools/release/chromium_r...
File tools/release/chromium_roll.py (right):

https://codereview.chromium.org/918953003/diff/20001/tools/release/chromium_r...
tools/release/chromium_roll.py:39: # Maybe delete that parameter entirely?
+1 for deleting it based on this rational, yet I don't know why it was added in
the first place. Was this expected to be specified by sheriffs who do new
release?

https://codereview.chromium.org/918953003/diff/20001/tools/release/chromium_r...
tools/release/chromium_roll.py:94: ROLL_SUMMARY % (self["last_rolled_base"][:8],
self["push_base"][:8]))
8chars*4bits = 32 bits should be enough for everybody :P

https://codereview.chromium.org/918953003/diff/20001/tools/release/common_inc...
File tools/release/common_includes.py (left):

https://codereview.chromium.org/918953003/diff/20001/tools/release/common_inc...
tools/release/common_includes.py:656: return latest_hash
On 2015/02/12 10:38:55, Michael Achenbach (OOO) wrote:
> Just returning here wouldn't be correct with the new branching strategy. It
> would include the version file change commit on the branch. For calculating
the
> change log that makes no difference, but for the summary of rolled changes it
is
> cleaner to not show it in my opinion.

Agree.

[Michael Achenbach, 2015-02-16 12:20:23]

The CQ bit was checked by machenbach@chromium.org

[Michael Achenbach, 2015-02-16 12:20:29]

https://codereview.chromium.org/918953003/diff/20001/tools/release/chromium_r...
File tools/release/chromium_roll.py (right):

https://codereview.chromium.org/918953003/diff/20001/tools/release/chromium_r...
tools/release/chromium_roll.py:39: # Maybe delete that parameter entirely?
On 2015/02/13 22:29:08, tandrii(chromium) wrote:
> +1 for deleting it based on this rational, yet I don't know why it was added
in
> the first place. Was this expected to be specified by sheriffs who do new
> release?

Some weird historical stuff. Probably needed if a push went completely wrong.

https://codereview.chromium.org/918953003/diff/20001/tools/release/chromium_r...
tools/release/chromium_roll.py:94: ROLL_SUMMARY % (self["last_rolled_base"][:8],
self["push_base"][:8]))
On 2015/02/13 22:29:08, tandrii(chromium) wrote:
> 8chars*4bits = 32 bits should be enough for everybody :P

I actually ran a test once over our repo and found out that the normal git
summary size of 7 is not enough. There is an ambiguous commit. Therefore we need
8.

[commit-bot: I haz the power, 2015-02-16 12:21:26]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/918953003/20001

[commit-bot: I haz the power, 2015-02-16 12:21:41]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-02-16 12:21:56]

Patchset 2 (id:??) landed as
https://crrev.com/15c269b760fdddc1d95e8e15dca6356f3854acb3
Cr-Commit-Position: refs/heads/master@{#26659}

[tandrii(chromium), 2015-02-16 14:32:28]

https://codereview.chromium.org/918953003/diff/20001/tools/release/chromium_r...
File tools/release/chromium_roll.py (right):

https://codereview.chromium.org/918953003/diff/20001/tools/release/chromium_r...
tools/release/chromium_roll.py:94: ROLL_SUMMARY % (self["last_rolled_base"][:8],
self["push_base"][:8]))
On 2015/02/16 12:20:28, Michael Achenbach wrote:
> On 2015/02/13 22:29:08, tandrii(chromium) wrote:
> > 8chars*4bits = 32 bits should be enough for everybody :P
> 
> I actually ran a test once over our repo and found out that the normal git
> summary size of 7 is not enough. There is an ambiguous commit. Therefore we
need
> 8.

So, I actually had some fun with this Birthday's paradox. At V8's current
commits number (~30k), there is 10% chance of a collision even with 8 chars!

============================================================
commits          probability of hash[:7] collission
   2324          0.010
   7522          0.100
  10000          0.170
  10946          0.200
  12429          0.250
  19291          0.500
  20000          0.525
  27282          0.750
  30000          0.813
  40000          0.949
  49723          0.990
  50000          0.991
============================================================
commits          probability of hash[:8] collission
   9292          0.010
  10000          0.012
  20000          0.045
  30000          0.099
  30085          0.100
  40000          0.170
  43782          0.200
  49712          0.250
  50000          0.253
============================================================

[Jakob Kummerow, 2015-02-16 19:54:54]

jkummerow@chromium.org changed reviewers:
+ jkummerow@chromium.org

[Jakob Kummerow, 2015-02-16 19:54:55]

DBC.

https://codereview.chromium.org/918953003/diff/20001/tools/release/chromium_r...
File tools/release/chromium_roll.py (right):

https://codereview.chromium.org/918953003/diff/20001/tools/release/chromium_r...
tools/release/chromium_roll.py:94: ROLL_SUMMARY % (self["last_rolled_base"][:8],
self["push_base"][:8]))
On 2015/02/16 14:32:28, tandrii(chromium) wrote:
> On 2015/02/16 12:20:28, Michael Achenbach wrote:
> > On 2015/02/13 22:29:08, tandrii(chromium) wrote:
> > > 8chars*4bits = 32 bits should be enough for everybody :P
> > 
> > I actually ran a test once over our repo and found out that the normal git
> > summary size of 7 is not enough. There is an ambiguous commit. Therefore we
> need
> > 8.
> 
> So, I actually had some fun with this Birthday's paradox. At V8's current
> commits number (~30k), there is 10% chance of a collision even with 8 chars!
> 
> ============================================================
> commits          probability of hash[:7] collission
>    2324          0.010
>    7522          0.100
>   10000          0.170
>   10946          0.200
>   12429          0.250
>   19291          0.500
>   20000          0.525
>   27282          0.750
>   30000          0.813
>   40000          0.949
>   49723          0.990
>   50000          0.991
> ============================================================
> commits          probability of hash[:8] collission
>    9292          0.010
>   10000          0.012
>   20000          0.045
>   30000          0.099
>   30085          0.100
>   40000          0.170
>   43782          0.200
>   49712          0.250
>   50000          0.253
> ============================================================

Just give it 12 chars or so (or 20, I don't care), to be reasonably safe for the
foreseeable future.