9 ms·

They mention that they'd ideally want a natural ordering on the commit hashes. Something to do with their zero-tolerence security policy. What's the background

by sedeki 4y ago

They mention that they'd ideally want a natural ordering on the commit hashes. Something to do with their zero-tolerence security policy. What's the background there? Why do they need a natural ordering?

nemetroid 4y ago
Zero-tolerance performance policy. You can find the policy [1] by searching the web. And the hashes don't have to be ordered. 1: https://webkit.org/performance/ https://webkit.org/performance/
- 0xfffafaCrash 4y ago
  I wonder if this policy, or the general mentality that produced it, is why webkit is so underdeveloped and widely reviled by devs compared to alternatives. Sounds like one can push in a security bug or performance increase that is fast because it is frankly completely broken, but wouldn’t be allowed to reverse the decision at least not without finding some alternative unrelated performance increase. Features or fixes that may obviously be worth an associated dip in performance can generally not be implemented. Under these conditions if I knew of ways to improve performance without adverse effect, as a developer I would sit on them instead of applying them because I would need a stockpile of reserves to apply in case of emergency to account for unrelated performance degrading changes that absolutely need to be made. I would also work to make sure the benchmarks were lousy and irrelevant. Policies like this can’t be written by people with any semblance of sense. Singular mindedness on one metric and extreme policies like this can kill development and subvert goals just as lack of discipline can. Everything is a balance. Weigh performance metrics heavily by all means, but absolutism leads to the absurd. I guess as long as Apple holds its monopoly on keeping iOS device browsers exclusively on Webkit, it will stick around though. Sadly having had years of an inside perspective on the competence level or lack thereof of decision makers in the non-revenue generating parts of their software business, can’t say this policy surprises me.
  - saagarjha 4y ago
    You wonder wrong.
Trufa 4y ago
I have literally 0 inside knowledge but from the article it seems to be a more human visual thing than a software problem, something like this was working in 12 and broken in 13 is a more obvious regression than this was working in aaab131 and broken in ccad53s
- LeifCarrotson 4y ago
  13 being greater than 12 is not a property that's just for human vision. In Subversion a commit on a branch increments the global commit number. Git doesn't have a concept of one commit being before or after another once you've branched, or any native mechanism for enforcing global state across branches.
- mattkrause 4y ago
  Sequential IDs also let you think about ranges: a feature was introduced in 11, broke in 17-23, and worked thereafter. I used SVN like this in grad school: data files included the SVN $Id$ of the script that generated them. This let you work around bugs and experimental changes. For example, you might hardcode a delay, realize it should be longer, and then eventually decide to let the experimenter adjust it on the fly. This is easy with sequential ids: if version < 11: delay = 50 elif 11 <= version < 29: delay = 100 else delay = params.delay Using git hashes, you'd need to maintain an exhaustive list of every version ever run, which is even tricker because there isn't a sole source of truth like an SVN repo.
  - cerved 4y ago
    I must be missing something because this seems odd, why isn't this code just different in each corresponding version?
    - mattkrause 4y ago
      The SVN-controlled code generated data by controlling hardware and embedded the $Id$ of the controlling script in its output. I would then refer to the version ID later, when loading that data in for analysis. This accounted for any changes to the data-generating code. For example, we tracked the orientation and direction of objects moving on a screen. One update redefined 0° to be up/north/12:00 instead of the +x direction used before. The code which loaded these files checked the $Id$ value and rotated the directional data so that the entire dataset used the same definition.
tln 4y ago
"zero-tolerance performance regression policy"... no patch can land if it regresses benchmarked performance. I'm guessing the tooling around this used subversion's increasing commit numbers and it was easier to add a shim to git, than to rewrite or rethink the tooling.
- usefulcat 4y ago
  > no patch can land if it regresses benchmarked performance ..unless it fixes some important security vulnerability, one hopes..
  - mhh__ 4y ago
    the trick is to change the benchmark at the same time
  - btown 4y ago
    Via https://webkit.org/performance/ https://webkit.org/performance/ : > If a patch lands that regresses performance according to our benchmarks, then the person responsible must either back the patch out of the tree or drop everything immediately and fix the regression. I imagine that a security hotfix would lead almost immediately to the second situation (perhaps as soon as the implementor had gotten some sleep!)
- xfmpXIe76lF4GfR 4y ago
  git literally has built-in tooling for this. It's called bisect (and they literally mention "bisection" in the next sentence).
  - howinteresting 4y ago
    The builtin tooling is insufficient for many purposes, including if your bisect algorithm requires you to run tests across many machines. Many large projects write their own bisect framework because of this.
    - 4y ago
anderskaseorg 4y ago
Git already has an ordering like this built in as ‘git describe’. https://git-scm.com/docs/git-describe https://git-scm.com/docs/git-describe $ git describe 593a2a5d0639b4b4f91ff6e6ffb64e72020f8fd8 v2.34.1-83-g593a2a5d06 This commit is 83 commits after the v2.34.1 tag. Git accepts this identifier anywhere it would accept a commit hash, e.g.: $ git log v2.34.1-83-g593a2a5d06 $ git show v2.34.1-83-g593a2a5d06:branch.c https://git.kernel.org/pub/scm/git/git.git/commit/?id=v2.34.1-83-g593a2a5d06 https://git.kernel.org/pub/scm/git/git.git/commit/?id=v2.34....
- cerved 4y ago
  they want a global, presumably centralized, order
  - Too 4y ago
    Describe works it’s way backwards to find a tag matching the search pattern. If you are checked out on origin/master and the tags come from the same centralized origin, then you will have a predictable global order. It’s basically the same thing as rev-list that they do, except more readable, with tighter integration to tags and with the result usable as a commitish.
- jamesfinlayson 4y ago
  Neat - I periodically see those incremental ids show up in places but didn't realised they worked like commit ids. But I'm not surprised.
  - iam-TJ 4y ago
    For all the interesting ways to name an object, see [0]: man 7 gitrevisions and for this particular naming "describeOutput" [0] https://manpages.debian.org/bullseye/git-man/gitrevisions.7.en.html https://manpages.debian.org/bullseye/git-man/gitrevisions.7....
kelnos 4y ago
I remember when I was migrating projects from svn to git, I was also concerned about the difficulty in telling order of commits at a glance. Turns out it ultimately doesn't matter, and after nearly 15 years using git, I have not once cared about ordering of commits.
bjackman 4y ago
Seems like the other commenters understand this already but it took me a while to figure it out so for anyone else that's confused: IIUC by "natural ordering" they mean you can tell the ordering just by looking at the IDs. Funnily enough I have the opposite desire - I've worked in a VC system with "natural ordering" and it once led to an incident, where I visually compared two version IDs and said "yep this release has the bug fix". Turns out this is hard to do accurately for big numbers and I was wrong. I put a big warning on our ops documentation saying "never compare version IDs visually" with a link to the postmortem!

by sedeki 4y ago

nemetroid 4y ago

Zero-tolerance performance policy. You can find the policy [1] by searching the web. And the hashes don't have to be ordered. 1: https://webkit.org/performance/ https://webkit.org/performance/

0xfffafaCrash 4y ago
I wonder if this policy, or the general mentality that produced it, is why webkit is so underdeveloped and widely reviled by devs compared to alternatives. Sounds like one can push in a security bug or performance increase that is fast because it is frankly completely broken, but wouldn’t be allowed to reverse the decision at least not without finding some alternative unrelated performance increase. Features or fixes that may obviously be worth an associated dip in performance can generally not be implemented. Under these conditions if I knew of ways to improve performance without adverse effect, as a developer I would sit on them instead of applying them because I would need a stockpile of reserves to apply in case of emergency to account for unrelated performance degrading changes that absolutely need to be made. I would also work to make sure the benchmarks were lousy and irrelevant. Policies like this can’t be written by people with any semblance of sense. Singular mindedness on one metric and extreme policies like this can kill development and subvert goals just as lack of discipline can. Everything is a balance. Weigh performance metrics heavily by all means, but absolutism leads to the absurd. I guess as long as Apple holds its monopoly on keeping iOS device browsers exclusively on Webkit, it will stick around though. Sadly having had years of an inside perspective on the competence level or lack thereof of decision makers in the non-revenue generating parts of their software business, can’t say this policy surprises me.
- saagarjha 4y ago
  You wonder wrong.

Trufa 4y ago

I have literally 0 inside knowledge but from the article it seems to be a more human visual thing than a software problem, something like this was working in 12 and broken in 13 is a more obvious regression than this was working in aaab131 and broken in ccad53s

LeifCarrotson 4y ago
13 being greater than 12 is not a property that's just for human vision. In Subversion a commit on a branch increments the global commit number. Git doesn't have a concept of one commit being before or after another once you've branched, or any native mechanism for enforcing global state across branches.
mattkrause 4y ago
Sequential IDs also let you think about ranges: a feature was introduced in 11, broke in 17-23, and worked thereafter. I used SVN like this in grad school: data files included the SVN $Id$ of the script that generated them. This let you work around bugs and experimental changes. For example, you might hardcode a delay, realize it should be longer, and then eventually decide to let the experimenter adjust it on the fly. This is easy with sequential ids: if version < 11: delay = 50 elif 11 <= version < 29: delay = 100 else delay = params.delay Using git hashes, you'd need to maintain an exhaustive list of every version ever run, which is even tricker because there isn't a sole source of truth like an SVN repo.
- cerved 4y ago
  I must be missing something because this seems odd, why isn't this code just different in each corresponding version?
  - mattkrause 4y ago
    The SVN-controlled code generated data by controlling hardware and embedded the $Id$ of the controlling script in its output. I would then refer to the version ID later, when loading that data in for analysis. This accounted for any changes to the data-generating code. For example, we tracked the orientation and direction of objects moving on a screen. One update redefined 0° to be up/north/12:00 instead of the +x direction used before. The code which loaded these files checked the $Id$ value and rotated the directional data so that the entire dataset used the same definition.

tln 4y ago

"zero-tolerance performance regression policy"... no patch can land if it regresses benchmarked performance. I'm guessing the tooling around this used subversion's increasing commit numbers and it was easier to add a shim to git, than to rewrite or rethink the tooling.

usefulcat 4y ago
> no patch can land if it regresses benchmarked performance ..unless it fixes some important security vulnerability, one hopes..
- mhh__ 4y ago
  the trick is to change the benchmark at the same time
- btown 4y ago
  Via https://webkit.org/performance/ https://webkit.org/performance/ : > If a patch lands that regresses performance according to our benchmarks, then the person responsible must either back the patch out of the tree or drop everything immediately and fix the regression. I imagine that a security hotfix would lead almost immediately to the second situation (perhaps as soon as the implementor had gotten some sleep!)
xfmpXIe76lF4GfR 4y ago
git literally has built-in tooling for this. It's called bisect (and they literally mention "bisection" in the next sentence).
- howinteresting 4y ago
  The builtin tooling is insufficient for many purposes, including if your bisect algorithm requires you to run tests across many machines. Many large projects write their own bisect framework because of this.
  - 4y ago

anderskaseorg 4y ago

Git already has an ordering like this built in as ‘git describe’. https://git-scm.com/docs/git-describe https://git-scm.com/docs/git-describe $ git describe 593a2a5d0639b4b4f91ff6e6ffb64e72020f8fd8 v2.34.1-83-g593a2a5d06 This commit is 83 commits after the v2.34.1 tag. Git accepts this identifier anywhere it would accept a commit hash, e.g.: $ git log v2.34.1-83-g593a2a5d06 $ git show v2.34.1-83-g593a2a5d06:branch.c https://git.kernel.org/pub/scm/git/git.git/commit/?id=v2.34.1-83-g593a2a5d06 https://git.kernel.org/pub/scm/git/git.git/commit/?id=v2.34....

cerved 4y ago
they want a global, presumably centralized, order
- Too 4y ago
  Describe works it’s way backwards to find a tag matching the search pattern. If you are checked out on origin/master and the tags come from the same centralized origin, then you will have a predictable global order. It’s basically the same thing as rev-list that they do, except more readable, with tighter integration to tags and with the result usable as a commitish.
jamesfinlayson 4y ago
Neat - I periodically see those incremental ids show up in places but didn't realised they worked like commit ids. But I'm not surprised.
- iam-TJ 4y ago
  For all the interesting ways to name an object, see [0]: man 7 gitrevisions and for this particular naming "describeOutput" [0] https://manpages.debian.org/bullseye/git-man/gitrevisions.7.en.html https://manpages.debian.org/bullseye/git-man/gitrevisions.7....

kelnos 4y ago

I remember when I was migrating projects from svn to git, I was also concerned about the difficulty in telling order of commits at a glance. Turns out it ultimately doesn't matter, and after nearly 15 years using git, I have not once cared about ordering of commits.

bjackman 4y ago

Seems like the other commenters understand this already but it took me a while to figure it out so for anyone else that's confused: IIUC by "natural ordering" they mean you can tell the ordering just by looking at the IDs. Funnily enough I have the opposite desire - I've worked in a VC system with "natural ordering" and it once led to an incident, where I visually compared two version IDs and said "yep this release has the bug fix". Turns out this is hard to do accurately for big numbers and I was wrong. I put a big warning on our ops documentation saying "never compare version IDs visually" with a link to the postmortem!