Merge lp://qastaging/~bladernr/checkbox/1077008-volume_test into lp://qastaging/checkbox

We could run this by mfisch (original test author) so that he can confirm this doesn't change their expectations. Other than that, this change makes a lot of sense.

11 - -- Jeff Lane <email address hidden> Wed, 07 Nov 2012 17:33:46 -0500
12 + -- Jeff Lane <email address hidden> Mon, 12 Nov 2012 13:00:19 -0500

Please don't change this line, it leads to conflicts

Other than that, ok +1 after you fix the changelog

Question is, why is this even an issue? Why is it creating conflicts? It's a result of using dch to edit the change log, which I have been doing for almost 3 years now. Why is this only NOW causing conflicts?

And why WOULDN'T I change that, anyway? It makes no sense to me for the changelog to have new entries from November 12, but a edit date of some time before November 12. Otherwise, it'll be April of next year and the change long would still say it was last edited on November 7 (using the last timestamp line).

Maybe there's just something here that I'm not grasping, but for 3 years this has not been an issue.

Question answered on the list, TARMAC!!!!!!

More importantly, pushed a branch with the fixed changelog. I also asked Matt Fischer about the change and this was his reply:

> If I recall correctly it was originally written that way and the test used values like -1 and 101 to test against 0
> and 100. I think we were asked to change this in a code review, but I'm fine with it being either way.

So we may want to let CEQA know about this change, in case they really do have test cases that use things like -1 and 101. that seems so counter-intuitive to me... I like my changes far better.

In other news, 2+2 = 5 and the square root of 32 is 6 and a half... Let's track down their test definitions and update them.

> Question answered on the list, TARMAC!!!!!!

No, it leads to conflicts with and without tarmac. If I also edit the changelog and replace that line it will conflict. Period.