split and update upstream status, as per template

howto/ldap.md

@@ -1387,6 +1387,81 @@ label.
  [file]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/new
  [search]: https://gitlab.torproject.org/tpo/tpa/team/-/issues?label_name%5B%5D=LDAP
 
+## Maintainer, users, and upstream
+
+Our [userdir-ldap repository][] is a fork of the [DSA userdir-ldap
+repository][]. The codebase is therefore shared with the Debian
+project, which uses it more heavily than TPO. According to [GitLab's
+analysis](https://salsa.debian.org/dsa-team/mirror/userdir-ldap/-/graphs/master), weasel has contributed the most to the repository (since
+2007), followed closely by Joey Schulze, which wrote most of the code
+before that, between 1999 and 2007.
+
+[DSA userdir-ldap repository]: https://salsa.debian.org/dsa-team/mirror/userdir-ldap
+[userdir-ldap repository]: https://gitweb.torproject.org/admin/userdir-ldap.git/
+
+The service is mostly in maintenance mode, both at DSA and in TPO,
+with small, incremental changes being made to the codebase over all
+those years. Attempts have been made to rewrite it with a Django
+frontend ([ud](https://github.com/Debian/ud), 2013-2014 no change since 2017) or Pylons
+([userdir-ldap-pylons](https://salsa.debian.org/dsa-team/mirror/userdir-ldap-pylons), 2011, abandoned), all have been abandoned.
+
+Our fork is primarily maintained by anarcat and weasel. It is used by
+*everyone* at Tor.
+
+Our fork tries to follow upstream as closely as possible, but the
+Debian project is hardcoded in a lot of places so we (currently) are
+forced to keep patches on top of upstream.
+
+### Branching policy
+
+In the [userdir-ldap][userdir-ldap repository] and [userdir-ldap-cgi repository][], we have
+tried to follow the [icebreaker branching strategy used at one of
+Google's kernel teams](https://lwn.net/Articles/871195/). Briefly, the idea is to have patches
+rebased on top of the latest upstream release, with each feature
+branch based on top of the tag. Those branches get merged in our
+"master" branch which contains our latest source code. When a new
+upstream release is done, a new feature branch is created by merging
+the previous feature branch and the new release.
+
+This pattern is designed so that it's easier to send patches
+upstream. Unfortunately, upstream releases are somewhat irregular so
+this somewhat breaks down because we don't have a solid branch point
+to base our feature branches off. This is why the branches are named
+like `tpo-scrub-0.3.104-pre-dd7f9a3`: the `pre-dd7f9a3` is to indicate
+that we are not branched off a real release.
+
+### usedir-ldap-cgi fork status
+
+In the [last sync](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40182), `usedir-ldap-cgi` was brought from 27 patches
+down to 16, 10 of which were sent upstream. Our diff there is now:
+
+      22 files changed, 11661 insertions(+), 553 deletions(-)
+
+The large number of inserted lines is because we included the
+[styleguide](https://styleguide.torproject.org) `bootstrap.css` which is 11561 lines on its own, so
+really, this is the diff stat if we ignore that stylesheet:
+
+      21 files changed, 100 insertions(+), 553 deletions(-)
+
+If the patches get merged upstream, our current delta is:
+
+     21 files changed, 23 insertions(+), 527 deletions(-)
+
+The only way forward here is either to make the "Debian" strings
+"variables" in the WML templates or completely remove the
+documentation from userdir-ldap-cgi (and move it to the project's
+respective wikis).
+
+### userdir-ldap fork status
+
+Our diff in `userdir-ldap` is much smaller:
+
+     6 files changed, 46 insertions(+), 19 deletions(-)
+
+We have 4 patches there, and a handful were merged upstream. The
+remaining patches could probably live as configuration files in
+Puppet, reducing the diff to nil.
+
 ## Monitoring and testing
 
 Nagios checks the `/var/lib/misc/thishost/last_update.trace` timestamp
@@ -1454,31 +1529,14 @@ Bacula.
 
 ## Overview
 
-`ud-ldap` is decades old (the `ud-generate` manpage mentions 1999, but
-it could be older) and is hard to debug and extend. This section aims
-at documenting issues with the software and possible alternatives.
-
-Our [userdir-ldap repository][] is a fork of the [DSA userdir-ldap
-repository][]. The codebase is therefore shared with the Debian
-project, which uses it more heavily than TPO. According to [GitLab's
-analysis](https://salsa.debian.org/dsa-team/mirror/userdir-ldap/-/graphs/master), weasel has contributed the most to the repository (since
-2007), followed closely by Joey Schulze, which wrote most of the code
-before that, between 1999 and 2007.
-
-[DSA userdir-ldap repository]: https://salsa.debian.org/dsa-team/mirror/userdir-ldap
-[userdir-ldap repository]: https://gitweb.torproject.org/admin/userdir-ldap.git/
+This section aims at documenting issues with the software and possible
+alternatives.
 
-The service is mostly in maintenance mode, both at DSA and in TPO,
-with small, incremental changes being made to the codebase over all
-those years. Attempts have been made to rewrite it with a Django
-frontend ([ud](https://github.com/Debian/ud), 2013-2014 no change since 2017) or Pylons
-([userdir-ldap-pylons](https://salsa.debian.org/dsa-team/mirror/userdir-ldap-pylons), 2011, abandoned), all have been abandoned.
-
-### Major issues with userdir-ldap
+`ud-ldap` is decades old (the `ud-generate` manpage mentions 1999, but
+it could be older) and is hard to maintain, debug and extend.
 
-ud-ldap is old, hard to maintain, and possibly has serious security
-issues. it is a liability, in the long term, in particular for those
-reasons:
+It might have serious security issues. It is a liability, in the long
+term, in particular for those reasons:
 
  * **old cryptographic primitives**: SHA-1 is used to hash `sudo`
    passwords, MD5 is used to hash user passwords, those hashes are