HOW TO CONTRIBUTE PATCHES TO OpenSSL ------------------------------------ (Please visit https://www.openssl.org/community/getting-started.html for other ideas about how to contribute.) Development is coordinated on the openssl-dev mailing list (see the above link or https://mta.openssl.org for information on subscribing). If you are unsure as to whether a feature will be useful for the general OpenSSL community you might want to discuss it on the openssl-dev mailing list first. Someone may be already working on the same thing or there may be a good reason as to why that feature isn't implemented. To submit a patch, make a pull request on GitHub. If you think the patch could use feedback from the community, please start a thread on openssl-dev to discuss it. Having addressed the following items before the PR will help make the acceptance and review process faster: 1. Anything other than trivial contributions will require a contributor licensing agreement, giving us permission to use your code. See https://www.openssl.org/policies/cla.html for details. 2. All source files should start with the following text (with appropriate comment characters at the start of each line and the year(s) updated): Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved. Licensed under the OpenSSL license (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 3. Patches should be as current as possible; expect to have to rebase often. We do not accept merge commits; You will be asked to remove them before a patch is considered acceptable. 4. Patches should follow our coding style (see https://www.openssl.org/policies/codingstyle.html) and compile without warnings. 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 Travis and AppVeyor are expected, and done whenever a PR is created or updated. 5. When at all possible, patches should include tests. These can either be added to an existing test, or completely new. Please see test/README for information on the test framework. 6. New features or changed functionality must include documentation. Please look at the "pod" files in doc/apps, doc/crypto and doc/ssl for examples of our style. href='/guix/log/gnu/packages/ld-wrapper.in?id=dd26713e16e0ed6798820eabf1af7aef34ece12f&showmsg=1'>Expand)Author 2020-03-05gnu: ld-wrapper: Add support for quoted arguments in response files.•••Marius Bakke 2018-03-29ld-wrapper: Allow linking with non-store libraries by default.•••Ludovic Courtès 2018-03-29ld-wrapper: Don't talk about "impure library".•••Ludovic Courtès 2018-03-29ld-wrapper: Make sure debugging output goes through.•••Ludovic Courtès 2017-05-25ld-wrapper: Read arguments from "response files".•••Ludovic Courtès 2016-04-06ld-wrapper: Unset 'GUILE_LOAD_COMPILED_PATH'.•••Ludovic Courtès 2015-11-28ld-wrapper: Compute the library search path globally.•••Ludovic Courtès