"Fossies" - the Fresh Open Source Software Archive

Member "bind-9.16.7/CONTRIBUTING" (4 Sep 2020, 7690 Bytes) of package /linux/misc/dns/bind9/9.16.7/bind-9.16.7.tar.xz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. See also the latest Fossies "Diffs" side-by-side code changes report for "CONTRIBUTING": 9.16.6_vs_9.16.7.

    1 CONTRIBUTING
    2 
    3 BIND 9 Source Access and Contributor Guidelines
    4 
    5 May 28, 2020
    6 
    7 Contents
    8 
    9  1. Access to source code
   10  2. Reporting bugs
   11  3. Contributing code
   12 
   13 Introduction
   14 
   15 Thank you for using BIND 9!
   16 
   17 BIND is open source software that implements the Domain Name System (DNS)
   18 protocols for the Internet. It is a reference implementation of those
   19 protocols, but it is also production-grade software, suitable for use in
   20 high-volume and high-reliability applications. It is very widely used DNS
   21 software, providing a robust and stable platform on top of which
   22 organizations can build distributed computing systems with the knowledge
   23 that those systems are fully compliant with published DNS standards.
   24 
   25 BIND is and will always remain free and openly available. It can be used
   26 and modified in any way by anyone.
   27 
   28 BIND is maintained by Internet Systems Consortium, a public-benefit 501(c)
   29 (3) nonprofit, using a "managed open source" approach: anyone can see the
   30 source, but only ISC employees have commit access. In the past, the source
   31 could only be seen once ISC had published a release; read access to the
   32 source repository was restricted just as commit access was. That has
   33 changed, as ISC now provides a public git mirror to the BIND source tree
   34 (see below).
   35 
   36 At ISC, we're committed to building communities that are welcoming and
   37 inclusive: environments where people are encouraged to share ideas, treat
   38 each other with respect, and collaborate towards the best solutions. To
   39 reinforce our commitment, ISC has adopted a slightly modified version of
   40 the Django Code of Conduct for the BIND 9 project, as well as for the
   41 conduct of our developers throughout the industry.
   42 
   43 Access to source code
   44 
   45 Public BIND releases are always available from the ISC FTP site.
   46 
   47 A public-access GIT repository is also available at https://gitlab.isc.org
   48 . This repository is a mirror, updated several times per day, of the
   49 source repository maintained by ISC. It contains all the public release
   50 branches; upcoming releases can be viewed in their current state at any
   51 time. It does not contain development branches or unreviewed work in
   52 progress. Commits which address security vulnerablilities are withheld
   53 until after public disclosure.
   54 
   55 You can browse the source online via https://gitlab.isc.org/isc-projects/
   56 bind9
   57 
   58 To clone the repository, use:
   59 
   60       $ git clone https://gitlab.isc.org/isc-projects/bind9.git
   61 
   62 Release branch names are of the form v9_X, where X represents the second
   63 number in the BIND 9 version number. So, to check out the BIND 9.12
   64 branch, use:
   65 
   66       $ git checkout v9_12
   67 
   68 Whenever a branch is ready for publication, a tag is placed of the form
   69 v9_X_Y. The 9.12.0 release, for instance, is tagged as v9_12_0.
   70 
   71 The branch in which the next major release is being developed is called
   72 master.
   73 
   74 Reporting bugs
   75 
   76 Reports of flaws in the BIND package, including software bugs, errors in
   77 the documentation, missing files in the tarball, suggested changes or
   78 requests for new features, etc., can be filed using https://gitlab.isc.org
   79 /isc-projects/bind9/issues.
   80 
   81 Due to a large ticket backlog, we are sometimes slow to respond,
   82 especially if a bug is cosmetic or if a feature request is vague or low in
   83 priority, but we try at least to acknowledge legitimate bug reports within
   84 a week.
   85 
   86 ISC's GitLab system is publicly readable; however, you must have an
   87 account to create a new issue. You can either register locally or use
   88 credentials from an existing account at GitHub, GitLab, Google, Twitter,
   89 or Facebook.
   90 
   91 Reporting possible security issues
   92 
   93 If you think you may be seeing a potential security vulnerability in BIND
   94 (for example, a crash with REQUIRE, INSIST, or ASSERT failure), please
   95 report it immediately by emailing to security-officer@isc.org. Plain-text
   96 e-mail is not a secure choice for communications concerning undisclosed
   97 security issues so please encrypt your communications to us if possible,
   98 using the ISC Security Officer public key.
   99 
  100 Do not discuss undisclosed security vulnerabilities on any public mailing
  101 list. ISC has a long history of handling reported vulnerabilities promptly
  102 and effectively and we respect and acknowledge responsible reporters.
  103 
  104 ISC's Security Vulnerability Disclosure Policy is documented at https://
  105 kb.isc.org/docs/aa-00861.
  106 
  107 If you have a crash, you may want to consult "What to do if your BIND or
  108 DHCP server has crashed."
  109 
  110 Contributing code
  111 
  112 BIND is licensed under the Mozilla Public License 2.0. Earlier versions
  113 (BIND 9.10 and earlier) were licensed under the ISC License
  114 
  115 ISC does not require an explicit copyright assignment for patch
  116 contributions. However, by submitting a patch to ISC, you implicitly
  117 certify that you are the author of the code, that you intend to relinquish
  118 exclusive copyright, and that you grant permission to publish your work
  119 under the open source license used for the BIND version(s) to which your
  120 patch will be applied.
  121 
  122 BIND code
  123 
  124 Patches for BIND may be submitted directly via merge requests in ISC's
  125 GitLab source repository for BIND.
  126 
  127 Patches can also be submitted as diffs against a specific version of BIND
  128 -- preferably the current top of the master branch. Diffs may be generated
  129 using either git format-patch or git diff.
  130 
  131 Those wanting to write code for BIND may be interested in the developer
  132 information page, which includes information about BIND design and coding
  133 practices, including discussion of internal APIs and overall system
  134 architecture.
  135 
  136 Every patch submitted is reviewed by ISC engineers following our code
  137 review process before it is merged.
  138 
  139 It may take considerable time to review patch submissions, especially if
  140 they don't meet ISC style and quality guidelines. If a patch is a good
  141 idea, we can and will do additional work to bring it up to par, but if
  142 we're busy with other work, it may take us a long time to get to it.
  143 
  144 To ensure your patch is acted on as promptly as possible, please:
  145 
  146   * Try to adhere to the BIND 9 coding style.
  147   * Run make check to ensure your change hasn't caused any functional
  148     regressions.
  149   * Document your work, both in the patch itself and in the accompanying
  150     email.
  151   * In patches that make non-trivial functional changes, include system
  152     tests if possible; when introducing or substantially altering a
  153     library API, include unit tests. See Testing for more information.
  154 
  155 Changes to configure
  156 
  157 If you need to make changes to configure, you should not edit it directly;
  158 instead, edit configure.in, then run autoconf. Similarly, instead of
  159 editing config.h.in directly, edit configure.in and run autoheader.
  160 
  161 When submitting a patch as a diff, it's fine to omit the configure diffs
  162 to save space. Just send the configure.in diffs and we'll generate the new
  163 configure during the review process.
  164 
  165 Documentation
  166 
  167 All functional changes should be documented. There are three types of
  168 documentation in the BIND source tree:
  169 
  170   * Man pages are kept alongside the source code for the commands they
  171     document, in files ending in .rst: for example, the named man page is
  172     bin/named/named.rst.
  173   * The BIND 9 Administrator Reference Manual is in the .rst files in doc/
  174     arm/; the PDF and HTML versions are automatically generated from the
  175     .rst files.
  176   * API documentation is in the header file describing the API, in
  177     Doxygen-formatted comments.
  178 
  179 Patches to improve existing documentation are also very welcome!
  180 
  181 Tests
  182 
  183 BIND is a large and complex project. We rely heavily on continuous
  184 automated testing and cannot merge new code without adequate test
  185 coverage. Please see the "Testing" section of doc/dev/dev.md for more
  186 information.
  187 
  188 Thanks
  189 
  190 Thank you for your interest in contributing to the ongoing development of
  191 BIND 9.