Once these patches are in trunk, we'll still need at least the following
to consider Python 3 support complete (the order in which these are
listed is arbitrary, any dependencies between them are pretty weak):

* CHANGES.txt and doc/upgrading.txt entries for the changes (not listing
every separate patch, but noting the presence of such changes and the
need to update .py and .html files copied into instances).

* Also merge Christof's followup patches (including a replacement /
fixed version of my patch 45) into trunk.

* Also update Jerrykan's mailgw changes
(https://github.com/jerrykan/herder/tree/mailgw last 6 commits) and get
those into trunk to eliminate mimetools use in mailgw.

* Complete getting the CI working to test commits with Python 3
automatically.

* Get the whole testsuite working cleanly with Python 3.

* Test all the front ends with Python 3 and get them working with it
(front ends are both not well-covered by the testsuite, and a place
where bytes/string conversions are particularly likely to be needed). 
By front ends I mean the different web interfaces where
doc/installation.txt says "There are five web interfaces to choose from"
(and then lists six, not five), not just what's in the frontends
directory - all six need to be made to work with Python 3 for us to be
able to document Python 3 support as on a par with that for Python 3.

* Similarly, make sure that incoming mail via roundup-mailgw works with
Python 3, for each different way documented for it to receive mail.

* Make sure that an existing instance, set up with Python 2, including
UTF-8 data in the database not just plain ASCII, works correctly when
used with Python 3 - that the database content format is properly
compatible across Python versions - with every database back end (the
reverse, creating with Python 3 and using with Python 2, may be less
important, but is still desirable - if someone has problems updating
their instance to Python 3, they should be able to move back to Python 2
without the stored data being incompatible).  anydbm may have the
highest risk of problems here, as it uses the Python marshal module in
storing data.

* Ensure that the CSV format used for export/import is properly
compatible across Python versions.  UTF-8 strings are included in
exports with \x escapes for the individual bytes of the UTF-8
representation (because that's how Python 2 does repr of a str object).
 Special care will be needed to keep this compatible for an export with
one Python version to be importable with another Python version.

* Update tokenize use in tools/pygettext.py (my patches only deal with
the use in cgitb.py).

* Convert scripts/roundup-reminder to use the email package instead of
the MimeWriter module which is no longer available with Python 3.

* Remove 2to3-done.txt once the text in there discussing Python 3
conversion plans is no longer relevant.  (I think the lists of files are
already not relevant.)

* Update all documentation to reflect the support for Python 3 as well
as for Python 2.  Documentation here includes the classifiers for pypi
in setup.py that currently include 'Programming Language :: Python :: 2
:: Only'.

* Get out an actual release with full Python 3 support (and then expect
users to find problems and so more fixed releases to be needed; I think
we should aim to have such releases reasonably frequently until the
Python 3 support seems solid in production use).

* Not actually needed for Python 3 support, but a good idea anyway:
prefer the standard library's PBKDF2 support in password handling
(available with Python 2.7.8, 3.4 and later).

* Not actually needed, but cleanup to consider: remove
roundup/admin.py:help_commands_html as apparently unused.

* Not actually needed, but cleanup to consider: remove FasterStringIO
completely.

* Not actually needed, but might be cleaner: distinguish String and
Bytes fields (and then consider having text and binary variants of
FileClass).