Bug 1507522 - Drop revision.txt and WR update process. r=jrmuizel
authorKartikaya Gupta <kgupta@mozilla.com>
Thu, 10 Jan 2019 14:14:13 +0000
changeset 510340 a51746f37520891be96522dbce8d1bade45d8b14
parent 510339 f68c74fea81e7a9ab4c5154f0ccc4d7154580243
child 510355 d0a6668cf2fe907399cff20030b7b8218d56f005
child 510382 ab507b25036a07b09e609c830079209e9ce8acc1
push id10547
push userffxbld-merge
push dateMon, 21 Jan 2019 13:03:58 +0000
treeherdermozilla-beta@24ec1916bffe [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1507522 - Drop revision.txt and WR update process. r=jrmuizel Differential Revision: https://phabricator.services.mozilla.com/D16105
--- a/gfx/webrender_bindings/README.webrender
+++ b/gfx/webrender_bindings/README.webrender
@@ -17,158 +17,8 @@ 4. Verify WebRender is enabled. You can 
 When making changes:
     - Make the changes you want.
     - Run |mach build| or |mach build binaries| as desired.
 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.
deleted file mode 100644
--- a/gfx/webrender_bindings/revision.txt
+++ /dev/null
@@ -1,1 +0,0 @@
--- a/gfx/webrender_bindings/src/bindings.rs
+++ b/gfx/webrender_bindings/src/bindings.rs
@@ -1694,18 +1694,16 @@ pub extern "C" fn wr_api_capture(
     // Use warn! so that it gets emitted to logcat on android as well
     let border = "--------------------------\n";
     warn!("{} Capturing WR state to: {:?}\n{}", &border, &path, &border);
     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();
         Err(e) => {
             warn!("Unable to create path '{:?}' for capture: {:?}", path, e);