diff --git a/TEST.rst b/TEST.rst
new file mode 100644
index 0000000..5754481
--- /dev/null
+++ b/TEST.rst
@@ -0,0 +1,83 @@
+Some thoughts on Eudyptula
+==========================
+
+Working with linux-next
+-----------------------
+
+Normally, we should follow Linux’s branch, and add **linux-next**
+remote, as explained in `kernel.org
+help <https://www.kernel.org/doc/man-pages/linux-next.html>`__.
+
+However, to build my own kernel for real usage, a stable one is much
+better, which tags are not in Linus’s branch.
+
+Adding Greg’s stable branch remote branch would just be a pain in the
+ass.
+
+However, I had this discussion on IRC:
+
+::
+
+   2021/05/13 11:40 <bodiccea> I am currently using Linus's branch, with another remote (linux-next).
+                               For the first time, I would like to use "for real" the latest stable
+                               (as of today: 5.12.3), but I cannot find such tag. I just added "stable"
+                               remote (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git),
+                               and currently it is being updated. Is it the correct way to have both
+                               linux-next and a useable/stable kernel ?
+   2021/05/13 12:12   <gregkh> bodiccea: yes.
+   2021/05/13 12:12   <gregkh> bodiccea: you can just use that linux.git tree as I keep it up to date
+                               with Linus's tree every -rc release at the longest, and sometimes daily
+                               if I'm bored :)
+   2021/05/13 12:13          * gregkh is reminded to go update it right now...
+
+So, the better is to completely forget about Linus’ branch. The
+procedure is therefore:
+
+1. **Clone gregkh’s stable blanch :**
+   ``$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git     Cloning into 'linux'...     ...``
+2. **Add a linux-next remote tracking branch :**
+   ``$ cd linux     $ git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git``
+3. **Fetch linux-next and tags :**
+   ``$ git fetch linux-next     $ git fetch --tags linux-next``
+4. **Regular tracking :**
+   ``$ git checkout master      # to be safe     ...     $ git remote update``
+
+Get latest versions
+-------------------
+
+1. **Latest stable versions**
+   ``$ git tag -l "v*" | grep -ve -rc | sort -V | tail -5     v5.11.22     v5.12     v5.12.1     v5.12.2     v5.12.3``
+2. **Latest -rc versions**
+   ``$ git tag -l "v*" | grep -e -rc | sort -V | tail -5     v5.12-rc6     v5.12-rc7     v5.12-rc8     v5.13-rc1     v5.13-rc2``
+3. **Latest linux-next versions**
+   ``$ git tag -l "next-*" | tail -5     next-20210512     next-20210513     next-20210514     next-20210518     next-20210519``
+
+Kernel config (Ubuntu)
+----------------------
+
+We should keep a .config somewhere, that we can use as a starting point
+for new kernels. Here: ../
+
+Doc: `issue with AD9467 <https://lkml.org/lkml/2021/3/18/1007>`__ (Fixed
+as of 5.12.5) `issue with signed
+kernel <https://askubuntu.com/questions/1329538/compiling-the-kernel-5-11-11>`__
+
+1. **First time, get latest Ubuntu kernel config file** \``\` $ cd linux
+   $ git checkout TAG $ cp /boot/config-x.y.z-t-generic .config $ make
+   olddefconfig
+
+   # disable trusted keys $ scripts/config –set-str SYSTEM_TRUSTED_KEYS
+   "" or: scripts/config –disable SYSTEM_TRUSTED_KEYS
+
+   $ cp .config ../kernel-config/$(git describe –tags) … \``\`
+
+2. **Then, just update config for new versions**
+   ``$ cd linux     $ git checkout TAG     $ cp ../kernel-config/TAG .config     $ make olddefconfig       or: make oldconfig     ...``
+
+Kernel build (deb package)
+--------------------------
+
+::
+
+   $ cd linux
+   $ make -j 2 bindeb-pkg LOCALVERSION=-bodi