Roadmap
#######

2.2.x (next)
************

Likely
======

* Drop all '< bookwom compatibility support'
	* (sphinx) Re-enable copybutton for 2.2.x
* Drop API call 'test_packages' (merge into testsuite packages)
* django: SQL schema migration: Get rid of all the workarounds in models just to stick to old schema

Brainstorm
==========

* Watcher support: Autoport and/or alarm on Debian Package Updates
* django: Integrate CAS/SSO-like features (python3-django-casclient?)
* Dependency check on package migration
* reprepro 5.4 (*needs to move out of experimental 1st*): Install multiple versions per distribution and drop all *rollback support*
* Make piuparts actually work (non-EXPERIMENTAL)
* gnupg: Switch completely to 'python3-gpg' (*NOT* 'python3-gpgme')
* Archive: Rethink Archive::mbd_ping (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740576)
* Release: Alternatives for NotAutomatic, ButAutomo...)?? Can we use more finegrained PRIOS on archives?
* sid-test-wildwest: Add extra suite for arbitrary package (deb+src) installs?
* Replace ftp by twisted/ssh?

2.0.x
*****

News
====

* New deb package layout: mini-buildd (the service), mini-buildd-utils (for users), python3-mini-buildd, mini-buildd-doc
* Code migration to ``python 3``
* Update to ``django 2.2`` (minimal version)
* Switch to ``twisted`` as http backend
* Support secure data channels (HTTPS && SFTP)
* API upgrade to json
* Event message queue
* Periodic task scheduler (cron, internal use)
* Automated repository snasphots (weekly, monthly, yearly)
* WEB UI rewrite
* Simplified maintenance (via new API call ``setup``)
* 'upgrade-compatible' (albeit **not** run-time-compatible) with 1.0.x (especially, there is no SQL schema change)
* Installable on bookworm, bullseye and buster

Upgrading from 1.0.x
====================

Package upgrade
---------------

Your ``1.0.x`` installation will typically run on a ``buster``-based system.

You may simply ``dist-upgrade`` / ``full-upgrade`` that system (1st to ``bullseye``, then to ``bookworm``) -- just make
sure the ``mini-buildd`` package is **never purged** during that process.

When done, you will need these extra APT sources:

* ``bookworm``: ``Debian Backports (bookworm-backports)`` -- *eventually available after Debian bookworm release*
* ``bullseye``: ``Hellfield Archive (bullseye-ab-stable)`` -- *eventually available after Debian bookworm release*

Alternatively: buster-based upgrade
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For convenience, it's still possible to run ``2.0.x`` under ``buster`` with some tweaks:

Extra APT sources needed:

* ``Debian Backports`` (buster-backports)
* ``Hellfield Archive`` (buster-ab-stable)

To upgrade, ``aptitude`` is imho the easiest way. Select the suggestion that de-installs py2 variants, and upgrades all the rest::

	aptitude install mini-buildd/buster-ab-stable

.. attention:: [buster-based install] 500 Internal Error: ``[Errno 2] No such file or directory: 'S.gpg-agent.extra'``

	 We see this error seemingly random on buster installations (w/ ``2.2.27-1~bpo10+1``) only so far.

	 * Removing a very old left-over ``~/.gnupg/gpg.conf`` seem to have helped so far on an actual host
	 * In test suite / chroot, it usually pops up with profile '_all'
	 * Never yet seen with default (no) profile or '_debian'

Post-upgrade checklist
----------------------

* ``mini-buildd`` command line arguments (``dpkg-reconfigure``) -- see :mbdcommand:`mini-buildd`
	* ``--httpd-bind`` is now deprecated in favor of ``--http-endpoint``
	* ``--verbose``, ``--quiet`` are now deprecated in favor of ``--log-level``. Also, giving *none* of these options now yields the recommended production log level (before, ``--verbose`` was default)
	* ``--debug`` now has some options removed (see man page). In general, never use it for production, ``--log-level=DEBUG`` should be good enough
* Decide if you want switch to ``https/ftps``: See :ref:`administrator:Running encrypted`
* File ``~/.mini-buildd.pid`` is no longer used, and may be removed (unless you use a custom setup using the old initv start/stop script)
* In case you have a custom upload setup, you can now add a custom dput snippet for convenience -- see :apicall:`dput_conf`
* Inspect/extend your setup, see :mbdpage:`setup`. Especially, check for these "model diff"s (which must be fixed manually):
	* ``Daemon.ftpd_bind``: Deprecates 'non-endpoint' notation
	* ``Daemon.gnupg_keyserver``: Please change to traditional keyserver (like ``keyserver.ubuntu.com``) to retain
	  functionality
	* ``Distribution.sbuildrc_snippet`` and ``Distribution.schroot_setup_script``. These most likely have legacy support code for
	  ccache and eatmydata, which is now supported by builtin ``ccache`` and ``eatmydata`` -- see
	  :ref:`administrator:Distribution`
* In case you hate the autogenerated complicated "Origin" text, you may now customize it -- see DB field ``Daemon.extra_options``
* Recommended to re-create all chroots -- see :apicall:`remake_chroots`, :mbdpage:`builders`

1.0.x
*****

Migrate packages from 0.8.x
===========================

.. tip:: Can I skip migrating from 0.8.x?

	Yes -- a much simpler solution might be to just copy the old repository directory (``~/rep``) somewhere and serve it
	via some standard web server, and just continue to use it along with your new repo as long as needed.

This roughly explains the steps needed to upgrade a mini-buildd 0.8.x installation to 1.0.x with **transferring the
packages from the old 0.8.x repositories over**, so you can continue with the new 1.0.x repos only:

1. Upgrade mini-buildd from 0.8.x to 1.0.

	 Chances are this might have already implicitly happened, with some update.

	 You will then have 1.0 up and running, and ye olde 0.8.x repositories still available as read-only apt repositories.

	 Just be sure you don't **purge** the old package, and then install 1.0, as this will remove the whole old repository.

2. Configure mini-buildd 1.0.

	 This means you should, in the end, have a 1.0 repository with the **same identity** as the old 0.8.x repository, and
	 with all distributions you want to migrate.

3. Import packages.

	 Become mini-buildd user, and got to the new 1.0 reprepro repository you want to import to, and use the importer
	 script to migrate packages:

	 .. code:: bash
			:class: mini-buildd-code

			cd repositories/REPOID
			mini-buildd-import-08x ~/rep/squeeze-REPOID-experimental squeeze-REPOID-experimental
			mini-buildd-import-08x ~/rep/squeeze-REPOID squeeze-REPOID-unstable

	 This example is for squeeze; repeat the imports for all base distributions you want to migrate.

	 Thusly, ye olde ``*-experimental`` distribution will be migrated to the distribution with the same name in 1.0. Ye
	 olde ``squeeze-REPOID`` goes to ``squeeze-REPOID-unstable``. For the latter, multiple package version will be
	 automatically installed to the new *rollback distributions* (which are needed with reprepro to support multiple
	 package versions).

4. (Optional) Fix up package status.

	 All the migrated packages are now in 1.0 "unstable" distribution; you may think of bulk-migrating them all to
	 "stable", if that were your semantics for the 0.8.x non-experimental distributions.

Eventually, when everything is updated, you may of course (re)move the old 0.8.x directory ``~/rep/``.

.. seealso:: :debbug:`790292`
