@@ -1,9 +1,11 @@
-# Copyright 1999-2021 The OpenSSL Project Authors. All Rights Reserved.
+#
+# Copyright 2025 The OpenSSL Project Authors. All Rights Reserved.
 #
 # Licensed under the Apache License 2.0 (the "License").  You may not use
 # this file except in compliance with the License.  You can obtain a copy
 # in the file LICENSE in the source distribution or at
 # https://www.openssl.org/source/license.html
+#
 
-#Reason codes
-DASYNC_R_INIT_FAILED:100:init failed
+--langmap=C:+.h
+--langmap=C:+.inc
@@ -19,13 +19,40 @@ open an issue for it before starting work, to get comments from the community.
 Someone may be already working on the same thing,
 or there may be special reasons why a feature is not implemented.
 
-Similarly, if you plan to submit many pull requests, please start with
-a representative sample (no more than 3 or 4) and open an issue
-explaining your process. The OpenSSL project has limited resources,
-especially when it comes to reviewers, so we appreciate advanced
-communication before submitting many pull requests. In addition,
-contributors should personally evaluate potential patches generated by
-automated tools.
+Do not submit changes in bulk.  Review, not authorship, is the scarce
+resource in this project: every pull request consumes the attention of
+at least two committers, and a batch of them submitted together does not get
+reviewed any faster than the same batch submitted over months.  It
+merely displaces the review of everyone else's work, including security
+fixes.
+
+Nor is the answer to bundle them together.  A pull request carrying
+twenty unrelated fixes is harder to review than any one of them alone,
+cannot be merged a piece at a time, and leaves every change in it blocked
+behind the one a reviewer disagrees with.  Each pull request should address
+one logical change (perhaps spread across multiple commits); what has to give
+is how many you submit, not how much you put in each one.
+
+Keep to no more than three or four open pull requests at a time, and let
+those be reviewed to completion before opening more.  If you are working
+through a list of candidate changes, then choose those three or four
+deliberately: send us the ones you consider most important, rather than the
+first on the list or the quickest to write, and explain in each why it
+matters.  You know your list; we do not, and without that ranking the
+judgement of what to look at first falls on the reviewers.  Pull requests
+opened well in excess of this may be closed without review, with a request to
+resubmit at a sustainable rate.
+
+This applies regardless of how good the individual changes are, and it
+is not satisfied by spacing submissions out over a few hours or days.
+
+You are the author of everything you submit, whatever produced the first
+draft of it.  Before opening a pull request you must have read the
+change in full, understood why it is correct, built and tested it
+yourself, and satisfied yourself that the problem it fixes is real.  You
+must be prepared to answer a reviewer's questions about any line of it.  The
+`Assisted-by:` trailer (see below) discloses that a tool was used; it does not
+transfer responsibility for the result.
 
 Provide a clear description of the issue or feature being addressed,
 including any relevant implementation details and, for performance
@@ -39,6 +66,16 @@ with clear explanations of what is changing and why.  Long descriptions
 are encouraged if they aid understanding.  Commit message titles (their
 first line) should be kept to 50-70 characters if possible.
 
+Pull Requests (PR's) go through multiple phases before they are merged. In the
+first phase the label 'approval: review pending' is added. Once you receive 2 or
+more approvals from [Committers] the label is changed to 'approval: done' and
+24 hours after this the label changes to 'approval: ready to merge'. At some time
+after this your PR will be merged and the PR is closed. Reviewers may ask you to
+make changes at any phase before the Pull Request is merged, and any changes
+(that are not just a rebase) will require re-approval.
+
+[Committers]: https://openssl-library.org/about/committers/index.html
+
 To make it easier to review and accept your pull request, please follow these
 guidelines:
 
@@ -117,19 +154,23 @@ guidelines:
     often. We do not accept merge commits, you will have to remove them
     (usually by rebasing) before it will be acceptable.
 
- 5. Code provided should follow our [coding style] and [documentation policy]
-    and compile without warnings.
-    There is a [Perl tool](util/check-format.pl) that helps
-    finding code formatting mistakes and other coding style nits.
+ 5. Code provided should follow our [coding style](STYLE.md) and
+    [documentation policy](DOCUMENTATION.md) and compile without warnings when
+    using a --strict-warnings configuration.
+
+    Consistent formatting is enforced by using `clang-format` with configuration
+    stored in [.clang-format](.clang-format). OpenSSL uses `WebKit` style.
+    You can configure git pre-commit to automatically reformat your code with
+    [.pre-commit-config.yaml](.pre-commit-config.yaml) configuration.
+    There is also a [Perl tool](util/reformat-patches.sh) to help with
+    reformatting existing patches.
+
     Where `gcc` or `clang` is available, you should use the
     `--strict-warnings` `Configure` option.  OpenSSL compiles on many varied
     platforms: try to ensure you only use portable features.
     Clean builds via GitHub Actions are required. They are started automatically
     whenever a PR is created or updated by committers.
 
-    [coding style]: https://openssl-library.org/policies/technical/coding-style/
-    [documentation policy]: https://openssl-library.org/policies/technical/documentation-policy/
-
  6. When at all possible, code contributions should include tests. These can
     either be added to an existing test, or completely new.  Please see
     [test/README.md](test/README.md) for information on the test framework.
@@ -152,3 +193,35 @@ guidelines:
 
  9. Guidelines on how to integrate error output of new crypto library modules
     can be found in [crypto/err/README.md](crypto/err/README.md).
+
+10. Once your Pull Request gets to the stage of being reviewed fixup commits
+    should be used where possible. Fixup commits are squashed when the PR is
+    finally merged. Fixup commits are done in the following way:
+
+    ```
+
+        # Add one or more updated files that needed changes
+        git add <filename>
+
+        # Do a fixup commit
+        # <commit-id> is the id of a previous commit that you want to fix up.
+        git commit --fixup <commit-id>
+
+        # Do a non forced push
+        git push
+    ```
+
+    To view commit-id's use:
+
+    ```
+       git log
+    ```
+
+11. If a Pull Request addresses an [issue](https://github.com/openssl/openssl/issues/)
+    the commit should include the line:
+
+    ```
+        Fixes: LINK
+    ```
+
+    where LINK is the https link to the issue in github.
@@ -47,7 +47,7 @@ my %targets=(
 
 	defines		=>
 	    sub {
-                my @defs = ( 'OPENSSL_BUILDING_OPENSSL' );
+                my @defs = ();
                 push @defs, "BROTLI" unless $disabled{brotli};
                 push @defs, "BROTLI_SHARED" unless $disabled{"brotli-dynamic"};
                 push @defs, "ZLIB" unless $disabled{zlib};