Lines Matching refs:changes

30 Zstd uses a branch-based workflow for making changes to the codebase. Typically, zstd
31 will use a new branch per sizable topic. For smaller changes, it is okay to lump multiple
32 related changes into a branch.
56         # make some changes =
60         * Note: run local tests to ensure that your changes didn't break existing functionality
76 … * When you are ready to share you changes to the community, create a pull request from your branch
79 …      * From there, select the branch where you made changes as your source branch and facebook:dev
84 …sufficiently summarize and motivate the changes they are proposing. We recommend all pull requests,
95 … * You will have to iterate on your changes with feedback from other collaborators to reach a point
105 …* Just because your changes have been merged does not mean the topic or larger issue is complete. …
109 …     suggest ways to refine and improve your initial changes even after the pull request is merged.
163 your changes on every single processor and os out there (and neither will we) but do that best
169 submitting changes that are clang-specific, windows-specific, etc.
183 do a little more work to ensure that you are in fact measuring the changes you've made not and
233 The fastest signal you can get regarding your performance changes is via the in-build zstd cli
258 changes. For example, the results of the example above indicate that effectively nothing
344 Zstd uses a number of different continuous integration (CI) tools to ensure that new changes