1 files changed, 209 insertions, 0 deletions
diff --git a/lang/python/doc/texinfo/short-history.texi b/lang/python/doc/texinfo/short-history.texi
new file mode 100644
index 0000000..a982f02
--- /dev/null
+++ b/lang/python/doc/texinfo/short-history.texi
@@ -0,0 +1,209 @@
+\input texinfo    @c -*- texinfo -*-
+@c %**start of header
+@setfilename short-history.info
+@settitle A Short History of the GPGME bindings for Python
+@documentencoding UTF-8
+@documentlanguage en
+@c %**end of header
+
+@finalout
+@titlepage
+@title A Short History of the GPGME bindings for Python
+@author Ben McGinnes
+@end titlepage
+
+@contents
+
+@ifnottex
+@node Top
+@top A Short History of the GPGME bindings for Python
+@end ifnottex
+
+@menu
+* Overview::
+* Relics of the past::
+
+@detailmenu
+--- The Detailed Node Listing ---
+
+Overview
+
+* In the beginning::
+* Keeping the flame alive::
+* Passing the torch::
+* Coming full circle::
+
+Relics of the past
+
+* The Annoyances of Git::
+* The Perils of PyPI::
+
+The Perils of PyPI
+
+* GPG 1·8·0 - Python bindings for GPGME GnuPG cryptography library::
+* PyME 0·9·0 - Python support for GPGME GnuPG cryptography library::
+
+@end detailmenu
+@end menu
+
+@node Overview
+@chapter Overview
+
+The GPGME Python bindings passed through many hands and numerous
+phases before, after a fifteen year journey, coming full circle to
+return to the source.  This is a short explanation of that journey.
+
+@menu
+* In the beginning::
+* Keeping the flame alive::
+* Passing the torch::
+* Coming full circle::
+@end menu
+
+@node In the beginning
+@section In the beginning
+
+In 2002 John Goerzen released PyME; Python bindings for the GPGME
+module which utilised the current release of Python of the time and
+SWIG.@footnote{In all likelihood thos would have been Python 2.2 or possibly
+Python 2.3.}  Shortly after creating it and ensuring it worked he stopped
+supporting it, though he left his work available on his Gopher
+site.
+
+@node Keeping the flame alive
+@section Keeping the flame alive
+
+A couple of years later the project was picked up by Igor Belyi and
+actively developed and maintained by him from 2004 to 2008.  Igor's
+whereabouts at the time of this document's creation are unknown,
+but the current authors do hope he is well.  We're assuming (or
+hoping) that life did what life does and made continuing untenable.
+
+@node Passing the torch
+@section Passing the torch
+
+In 2014 Martin Albrecht wanted to patch a bug in the PyME code and
+discovered the absence of Igor.  Following a discussion on the PyME
+mailing list he became the new maintainer for PyME, releasing
+version 0.9.0 in May of that year.  He remains the maintainer of
+the original PyME release in Python 2.6 and 2.7 (available via
+PyPI).
+
+@node Coming full circle
+@section Coming full circle
+
+In 2015 Ben McGinnes approached Martin about a Python 3 version,
+while investigating how complex a task this would be the task ended
+up being completed.  A subsequent discussion with Werner Koch led
+to the decision to fold the Python 3 port back into the original
+GPGME release in the languages subdirectory for non-C bindings
+under the module name of @samp{pyme3}.
+
+In 2016 this PyME module was integrated back into the GPGME project
+by Justus Winter.  During the course of this work Justus adjusted
+the port to restore limited support for Python 2, but not as many
+minor point releases as the original PyME package supports.  During
+the course of this integration the package was renamed to more
+accurately reflect its status as a component of GPGME.  The @samp{pyme3}
+module was renamed to @samp{gpg} and adopted by the upstream GnuPG team.
+
+In 2017 Justus departed G10code and the GnuPG team.  Following this
+Ben returned to maintain of gpgme Python bindings and continue
+building them from that point.
+
+@node Relics of the past
+@chapter Relics of the past
+
+There are a few things, in addition to code specific factors, such as
+SWIG itself, which are worth noting here.
+
+@menu
+* The Annoyances of Git::
+* The Perils of PyPI::
+@end menu
+
+@node The Annoyances of Git
+@section The Annoyances of Git
+
+As anyone who has ever worked with git knows, submodules are
+horrible way to deal with pretty much anything.  In the interests
+of avoiding migraines, that was skipped with addition of the PyME
+code to GPGME.
+
+Instead the files were added to a subdirectory of the @samp{lang/}
+directory, along with a copy of the entire git log up to that point
+as a separate file within the @samp{lang/python/docs/} directory.@footnote{The entire PyME git log and other preceding VCS logs are
+located in the @samp{gpgme/lang/python/docs/old-commits.log} file.}
+As the log for PyME is nearly 100KB and the log for GPGME is
+approximately 1MB, this would cause considerable bloat, as well as
+some confusion, should the two be merged.
+
+Hence the unfortunate, but necessary, step to simply move the
+files.  A regular repository version has been maintained should it
+be possible to implement this better in the future.
+
+@node The Perils of PyPI
+@section The Perils of PyPI
+
+The early port of the Python 2 @samp{pyme} module as @samp{pyme3} was never
+added to PyPI while the focus remained on development and testing
+during 2015 and early 2016.  Later in 2016, however, when Justus
+completed his major integration work and subsequently renamed the
+module from @samp{pyme3} to @samp{gpg}, some prior releases were also
+provided through PyPI.
+
+Since these bindings require a matching release of the GPGME
+libraries in order to function, it was determined that there was
+little benefit in also providing a copy through PyPI since anyone
+obtaining the GPGME source code would obtain the Python bindings
+source code at the same time.  Whereas there was the potential to
+sew confusion amongst Python users installing the module from PyPI,
+only to discover that without the relevant C files, header files or
+SWIG compiled binaries, the Python module did them little good.
+
+There are only two files on PyPI which might turn up in a search
+for this module or a sample of its content:
+
+@enumerate
+@item
+gpg (1.8.0) - Python bindings for GPGME GnuPG cryptography library
+@item
+pyme (0.9.0) - Python support for GPGME GnuPG cryptography library
+@end enumerate
+
+@menu
+* GPG 1·8·0 - Python bindings for GPGME GnuPG cryptography library::
+* PyME 0·9·0 - Python support for GPGME GnuPG cryptography library::
+@end menu
+
+@node GPG 1·8·0 - Python bindings for GPGME GnuPG cryptography library
+@subsection GPG 1·8·0 - Python bindings for GPGME GnuPG cryptography library
+
+This is the most recent version to reach PyPI and is the version
+of the official Pyhon bindings which shipped with GPGME 1.8.0.  If
+you have GPGME 1.8.0 installed and @emph{only} 1.8.0 installed, then it
+is probably safe to use this copy from PyPI.
+
+As there have been a lot of changes since the release of GPGME
+1.8.0, the GnuPG Project recommends not using this version of the
+module and instead installing the current version of GPGME along
+with the Python bindings included with that package.
+
+@node PyME 0·9·0 - Python support for GPGME GnuPG cryptography library
+@subsection PyME 0·9·0 - Python support for GPGME GnuPG cryptography library
+
+This is the last release of the PyME bindings maintained by Martin
+Albrecht and is only compatible with Python 2, it will not work
+with Python 3.  This is the version of the software from which the
+port from Python 2 to Python 3 code was made in 2015.
+
+Users of the more recent Python bindings will recognise numerous
+points of similarity, but also significant differences.  It is
+likely that the more recent official bindings will feel "more
+pythonic."
+
+For those using Python 2, there is essentially no harm in using
+this module, but it may lack a number of more recent features
+added to GPGME.
+
+@bye
+\ No newline at end of file