diff options
Diffstat (limited to 'lang/python/doc/src/maintenance-mode')
| -rw-r--r-- | lang/python/doc/src/maintenance-mode | 93 |
1 files changed, 93 insertions, 0 deletions
diff --git a/lang/python/doc/src/maintenance-mode b/lang/python/doc/src/maintenance-mode new file mode 100644 index 00000000..ef56e4e6 --- /dev/null +++ b/lang/python/doc/src/maintenance-mode @@ -0,0 +1,93 @@ +# -*- mode: org -*- +#+TITLE: Maintenance Mode +#+AUTHOR: Ben McGinnes +#+LATEX_COMPILER: xelatex +#+LATEX_CLASS: article +#+LATEX_CLASS_OPTIONS: [12pt] +#+LATEX_HEADER: \usepackage{xltxtra} +#+LATEX_HEADER: \usepackage[margin=1in]{geometry} +#+LATEX_HEADER: \setmainfont[Ligatures={Common}]{Times New Roman} +#+LATEX_HEADER: \author{Ben McGinnes <[email protected]>} + + +* Maintenance Mode from 2019 + :PROPERTIES: + :CUSTOM_ID: maintenance-mode + :END: + +| Version: | 0.0.1-draft | +| GPGME Version: | 1.13.0 | +| Author: | [[https://gnupg.org/people/index.html#sec-1-5][Ben McGinnes]] <[[mailto:[email protected]][[email protected]]]> | +| Author GPG Key: | [[https://hkps.pool.sks-keyservers.net/pks/lookup?search=0xDB4724E6FA4286C92B4E55C4321E4E2373590E5D&exact=on&op=get][DB4724E6FA4286C92B4E55C4321E4E2373590E5D]] | +| Language: | Australian English, British English | +| xml:lang: | en-AU, en-GB, en | + +From the beginning of 2019 the Python bindings to GPGME will enter +maintenance mode, meaning that new features will not be added and only +bug fixes and security fixes will be made. This also means that +documentation beyond that existing at the end of 2018 will not be +developed further except to correct errors. + +Though use of these bindings appears to have been quite well received, +there has been no indication of what demand there is, if any for +either financial backing of the current Python bindings development or +support contracts with g10code GmbH citing the necessity of including +the bindings. + + +** Maintainer from 2019 onward + :PROPERTIES: + :CUSTOM_ID: maintenance-mode-bm + :END: + +How does this affect the position of GnuPG Python Bindings Maintainer? + +Well, I will remain as maintainer of the bindings; but without funding +for that position, the amount of time I will be able to dedicate +solely to this task will be limited and reduced to volunteered time. +As with all volunteered time and effort in free software projects, +this will be subject to numerous external imperatives. + + +** Using the Python Bindings from 2019 and beyond + :PROPERTIES: + :CUSTOM_ID: maintenance-mode-blade-runner + :END: + +For most, if not all, Python developers using these bindings; they +will continue to “just work” the same as they always have. Expansions +of GPGME itself are usually handled by SWIG with the existing code and +thus bindings are generated properly when the bindings are installed +alongside GPGME and when the latter is built from source. + +In the rare circumstances where that is not enough to address some new +addition to GPGME, then that is a bug and thus subject to the +maintenance mode provisions (i.e. it will be fixed following a bug +report being raised and your humble author will need to remember where +the timesheet template was filed, depending on how many years off such +an event is). + +All the GPGME functionality will continue to be accessible via the +lower level, dynamically generated methods which match the GPGME C +documentation. While the more intuitively Pythonic higher level layer +already covers the vast majority of functionality people require with +key generation, signatures, certifications (key signing), encryption, +decryption, verification, validation, trust levels and so on. + +Any wanted features lacking in the Python bindings are usually lacking +because they are missing from GPGME itself (e.g. revoking keys via the +API) and in such cases they are usually deliberately excluded. More + +Any features existing in the dynamically generated layer for which +people want a specific, higher level function included to make it more +Pythonic (e.g. to avoid needing to learn or memorise cryptographic +mode values or GnuPG status code numbers), would be a feature request +and /not/ a bug. + +It is still worthwhile requesting it, but the addition of such a +feature would not be guaranteed and provided on a purely volunteer +basis. Expediting such a request would require funding that request. + +Those with a commercial interest in expediting such a feature request +already know how to [[https://gnupg.org/cgi-bin/procdonate.cgi?mode=preset][expedite it]] (use the message field to state what +feature is being requested). |