Bug 1507522 - Drop revision.txt and WR update process. r=jrmuizel

Differential Revision: https://phabricator.services.mozilla.com/D16105

--HG--
extra : moz-landing-system : lando

gfx/webrender_bindings/README.webrender

@@ -22,153 +22,3 @@ For a debug webrender build:
     Use a debug mozconfig (ac_add_options --enable-debug)
     You can also use an opt build but make webrender less optimized by putting opt-level=0 in the [profile.release] section of your toolkit/library/rust/Cargo.toml file
     See also https://groups.google.com/forum/#!topic/mozilla.dev.servo/MbeMcqqO1fs
-
---------------------------------------------------------------------------------
-
-What if you have to pull in an update to webrender itself? You have two options,
-listed below. Both options will give you a set of patches and the ability to do
-try pushes to verify the update. After that, continue with the steps below to
-actually land the update into the tree.
-
-Option A:
-   Use a script to do the update for you. This will usually work, if you satisfy
-   all the assumptions the script is making. The script can be found at
-   https://github.com/staktrace/wrupdater/blob/master/try-latest-webrender.sh
-   and contains documentation on how to use it. Read the documentation carefully
-   before trying to use it.
-
-Option B:
-   Do the update manually. This is a little more cumbersome but may be required
-   if the script doesn't work or the repos are in a state that violates hidden
-   assumptions in the script (e.g. if the webrender_bindings/Cargo.toml file is
-   no longer in the format expected by the script). The steps to do this are,
-   roughly:
-   - Update your mozilla-central checkout to the latest code on mozilla-central.
-   - Check out and update the webrender repo to the version you want
-   - Copy over the webrender repo to gfx/wr. The easiest way to do this is
-     simply delete gfx/wr, and use |cp -R| to copy it back, and then delete the
-     gfx/wr/.git/ subfolder. Update the revision in
-     gfx/webrender_bindings/revision.txt file with the git changeset hash.
-   - If you need to modify webrender_bindings/Cargo.toml file, do so now. Changes
-     at this step usually consist of:
-     (a) Updating version numbers. Go through the version numbers of ALL the
-         dependencies in the Cargo.toml file (webrender, euclid, etc.) and make
-         sure the version numbers listed match what's in the new
-         gfx/wr/webrender/Cargo.toml and gfx/wr/webrender_api/Cargo.toml files.
-     (b) Turning on or off any new features that were added in upstream WR. This
-         used to happen a lot but is pretty rare now.
-   - Go to toolkit/library/rust and run |cargo update -p webrender -p webrender_api|.
-     If it complains about version numbers of other crates not lining up, add those
-     as well, e.g. |cargo update -p webrender -p webrender_api -p gleam -p euclid|.
-     You may need to do this a few times until you get all the crates to make it
-     happy.
-   - Run the same cargo update command from the previous step in the
-     toolkit/library/gtest/rust folder.
-   - Commit your changes locally. You'll need to do this before the next step or
-     it will complain.
-   - At the top of the tree, run |mach vendor rust| to update the rust
-     dependencies in third_party/rust.
-   - Commit your changes locally.
-   - Build and test. You may need to make changes in bindings.rs or on the C++
-     side depending on what changed in webrender. This can potentially be quite
-     tricky if you don't fully understand the API changes on the webrender side.
-     Get help if you need it. For simplicity in bisecting, try to not use your
-     new features yet, just get the build working with the minimal changes.
-   - Commit any changes from the previous step, and do a try push to make sure
-     everything is good. Generally we do two try pushes, one for builds and
-     linux tests. This should be totally green. The other forces WR enabled on
-     Windows and runs reftests, which currently fails. However if it fails with
-     more than just regular reftest failures (e.g. it crashes or has an assertion
-     failure) then that's potentially going to be a problem for Windows users
-     running WebRender and will need investigation.
-   - You now have an updated webrender, so you can land it or write gecko
-     code against the new features.
-
-Once you have followed either Option A or Option B and have a good update, you
-might want to land it in the tree. To do this:
-- Find the current wr-future-update bug, by going to https://bugzil.la/wr-future-update
-- Clone this bug (there is a little dropdown in the bottom right corner of the
-  page which gives you an option to "Create a new bug ... as a clone of this bug").
-- This will take you to a bug entry page with some stuff prepopulated. Do NOT
-  submit it yet, but make the following changes:
-  (a) Modify the "Description" to remove the SECOND instance of the text "+++ This
-      bug was initially created as a clone of ... +++". Keep the first instance
-      as it points to the bug you just cloned, and keep the rest of the text unless
-      you feel it needs changing.
-  (b) Add wr-future-update into the "Alias" field
-  (c) Clear the bugs in the "Depends on" field
-  (d) For each bug in the "Blocks" field, except for 1311790 and 1386670, go
-      to the bug and check the "See Also" link for the corresponding WR issue/PR,
-      if any. If there is a WR issue that is not yet resolved in the update you
-      are landing, leave the bug in the "Blocks" field of your clone. In a later
-      step you will remove the dependency from the update you are landing. At
-      end of this step the "Blocks" field should contain 1311790, 1386670, and
-      any bugs tracking upstream WR issues that are not fixed in the update.
-  (e) You still cannot submit the clone as a new bug, because you can't have two
-      bugs in the system with the same alias. So hold on a sec.
-- Go back to the tab with the current wr-future-update bug, and click on the edit
-  button. Make the following changes:
-  (a) Assign the bug to yourself.
-  (b) Clear the "Alias" field.
-  (c) Remove bugs from the "Blocks" field that you kept in step (d), other than
-      1311790 and 1386670. In other words, update the "Blocks" field so that it
-      contains 1311790, 1386670, and any bugs that are actually fixed by the
-      update.
-  (d) Submit your changes to this bug.
-- Now you can submit your changes to the clone bug which will create a new
-  wr-future-update bug.
-- Update your patch queue so that the patches are properly formatted with
-  bug number, reviewer, etc. and push to MozReview. This is kind of important,
-  because you want these patches to land on autoland rather than inbound. If it
-  lands on inbound there's a high chance of it conflicting with the servo-vcs-sync
-  bot that is regularly pushing to autoland, and then you'll only find out about
-  it when the sheriff tries to do a merge and backs you out. If you push to
-  autoland you're likely to find out about the problem at push time, when the
-  patches won't rebase.
-
-
-Troubleshooting tips:
-
-1. Note that when webrender is built as part of gecko, it may end up using slightly
-   different versions of its dependencies than when it is built standalone from the
-   webrender repo. The reason is that the Cargo.lock files in m-c and in the WR
-   repo may reference different versions of the dependencies. Both builds will be
-   compatible in terms of semantic versioning, but may produce different results -
-   for example the standalone webrender might use euclid 0.10.4 while the
-   one in gecko uses euclid 0.10.3. Although both choices are "valid" per
-   the semantic versioning rules in webrender's Cargo.toml, the 0.2.3 may provide
-   a bugfix that is needed for correct behaviour in webrender. If this is the case,
-   the technically "correct" fix is to change the upstream webrender Cargo.toml
-   file to require the correct version. Alternnatively, you can update the
-   Cargo.lock files in m-c to pull in the new version. The way to do this is as
-   follows:
-   - Go to toolkit/library/rust and run |cargo update -p <package> --precise <version>|.
-     Repeat this for as many libraries as you need to update. Run the same commands
-     in toolkit/library/gtest/rust and js/src (ignore any errors about unmatched
-     packages). Commit all the changes locally.
-   - Run |mach vendor rust|, which will update the corresponding libraries in
-     third_party/rust to the versions you specified.
-   The reason we don't do this by default is to work around bug 1336528. Specifically,
-   there is another crate in m-c called mozjs_sys which is built separately but uses
-   the same folder to store its rust dependencies. If one of the libraries that is
-   required by both mozjs_sys and webrender is updated without updating the other
-   project's Cargo.lock file, that results in build bustage.
-   This means that any time you do this sort of manual update of packages, you need
-   to make sure that mozjs_sys also has its Cargo.lock file updated if needed, hence
-   the need to run the cargo update command in js/src as well. Hopefully this will
-   be resolved soon.
-
-2. Sometimes autoland tip has changed enough from mozilla-central (because of the
-   servo vcs-sync-bot, which will sync servo into m-c and often re-vendor third-
-   party rust dependencies) that trying to land an update based on mozilla-central
-   will not work well. As in, you'll get conflicts in Cargo.lock files or in the
-   third_party/rust directory. This is best handled by running your update steps
-   on top of autoland tip rather than central. (The script-based update in option A
-   has an env var you can set to do this). In theory you can get the same
-   result by resolving the conflict manually but Cargo.lock files are usually not
-   trivial to merge by hand. If it's just the third_party/rust dir that has conflicts
-   you can delete it and run |mach vendor rust| again to repopulate it.
-
--------------------------------------------------------------------------------
-
-The current WebRender revision can be found in gfx/webrender_bindings/revision.txt file.

gfx/webrender_bindings/revision.txt

@@ -1 +0,0 @@
-d3edc30cf95d3c96fd8308969b22062698a0f6ce

gfx/webrender_bindings/src/bindings.rs

@@ -1699,8 +1699,6 @@ pub extern "C" fn wr_api_capture(
     let _ = create_dir_all(&path);
     match File::create(path.join("wr.txt")) {
         Ok(mut file) => {
-            let revision = include_bytes!("../revision.txt");
-            file.write(revision).unwrap();
             // The Gecko HG revision is available at compile time
             if let Some(moz_revision) = option_env!("GECKO_HEAD_REV") {
                 writeln!(file, "mozilla-central {}", moz_revision).unwrap();