bugsink 0.1.12__tar.gz

bugsink-0.1.12/.github/workflows/ci.yml

@@ -0,0 +1,79 @@
+name: Continuous Integration
+
+on:
+  push:
+    branches: [ "main" ]
+  pull_request:
+    branches: [ "main" ]
+
+env:
+  DJANGO_SETTINGS_MODULE: "bugsink.settings.development"
+
+jobs:
+  flake8:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v4
+    - name: "Set up Python 3.11"
+      uses: actions/setup-python@v5
+      with:
+        python-version: "3.11"  # below 3.12 to avoid false positives inside f-string
+    - name: Install Flake8
+      run: |
+        python -m pip install --upgrade flake8
+    - name: Run Flake8
+      run: |
+        # We ignore 2 classes of whitespace errors (which are useful in the local context,
+        # but not worth breaking the build).
+        # https://github.com/PyCQA/flake8/issues/515 shows a dead end of doing this "properly"
+        # so we just specify it on the command line
+        flake8 --extend-ignore=E127,E741,E501 `git ls-files | grep py$`
+
+  test:
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        python-version: ["3.8", "3.9", "3.10", "3.11", "3.12"]
+    steps:
+    - uses: actions/checkout@v4
+    - name: Set up Python ${{ matrix.python-version }}
+      uses: actions/setup-python@v5
+      with:
+        python-version: ${{ matrix.python-version }}
+    - name: Install build
+      run: |
+        python -m pip install --upgrade pip
+        pip install build
+    - name: Build wheel
+      run: |
+        python -m build --wheel
+    - name: Install from wheel
+      run: |
+        python -m pip install dist/*.whl
+    - name: Install development dependencies
+      run: |
+        pip install -r requirements.development.txt
+    - name: Check out event-samples
+      uses: actions/checkout@master
+      with:
+        repository: bugsink/event-samples
+        path: "event-samples"
+    - name: Create separate dir to avoid accidentally using non-packaged code
+      run: |
+        mkdir separate_dir
+    - name: Run Makemigrations --check
+      working-directory: separate_dir
+      run: |
+        bugsink-manage makemigrations --check
+    - name: Run Tests
+      working-directory: separate_dir
+      env:
+        SAMPLES_DIR: "${{ github.workspace }}/event-samples"
+        PYTHONWARNINGS: all
+      run: |
+        # because we're outside the project directory, the test discovery won't find our packages. We simply enumerate
+        # them using some shell-magic. Note that the only non-app that we still care about is 'bugsink' (project, not app)
+        # which we mention separately
+        bugsink-manage test `bugsink-manage shell -c 'from django.conf import settings; print(" ".join(settings.BUGSINK_APPS))'` bugsink -v2
+        # bugsink-manage test ${GITHUB_WORKSPACE}  -v2  # fails with the following, which I don't understand:
+        # ImportError: 'tests' module incorrectly imported from '/opt/hostedtoolcache/Python/3.10.15/x64/lib/python3.10/site-packages/alerts'. Expected '/home/runner/work/bugsink-private/bugsink-private/alerts'. Is this module globally installed? 

bugsink-0.1.12/.gitignore

@@ -0,0 +1,51 @@
+# Python
+*.pyc
+__pycache__
+
+# Virtual Environments / build
+/.env
+/.venv
+/bin/
+/include/
+/lib/
+/lib64
+/pyvenv.cfg
+/share/
+/bugsink.egg-info/
+/bugsink/_version.py
+/dist/
+
+
+# sqlite
+/db.sqlite3
+/db.*.sqlite3
+/test.sqlite3
+
+/db.sqlite3-wal
+/db.*.sqlite3-wal
+/test.sqlite3-wal
+
+/db.sqlite3-shm
+/db.*.sqlite3-shm
+/test.sqlite3-shm
+
+/snappea.sqlite3
+/snappea.sqlite3-shm
+/snappea.sqlite3-wal
+
+# vim
+*.swo
+*.swp
+
+# node (tailwind)
+node_modules
+/package*
+
+# conf
+/bugsink_conf.py
+
+# static files
+/collectedstatic
+
+# Docker artifacts
+/bugsink*tar

bugsink-0.1.12/DESIGN-alerts.md

@@ -0,0 +1,77 @@
+# Alert Rules
+
+## Opinionated take
+
+Default setting, may be adapted at organisational level.
+
+You should get alerts for any state change for the worse, such as:
+
+* New issues
+* Regressions
+* Unmuting (could be due to volume)
+
+The basic belief underlying this is: "you should care about the errors on your project". And therefore, you'll be
+alerted when they occur.
+
+### Volume-Based Rules for unmuting
+
+Volume based rules may be configured per-issue for unmuting. e.g.
+
+- First time  more than 5 events per the last 3 hours occur
+- First time more than 10 events per day
+- First time the total number of events exceeds 100
+
+The idea is: "I know about this issue, I've determined it's not important, and I only want to get notified when it start
+occurrung a lot (for some definition of 'a lot')"
+
+The tie-in with alerts is: you can send notification on-unmute. (by the definition of unmuting, the alert
+occurs only the _first time_ the condition occurs)
+
+## "Later": auto-mute w/ default unmute rules
+
+At some point we may make it so that you can configure per-project that issues are initially muted (on create) but with
+some predefined set of volume-based unmute conditions, which is set on the muted issues on-create.
+
+(This is in place of project-level volume-based alert settings. The main reason for this is that I want to keep a
+symmetry/tracability between what's going on in the UI and the alerts that are going out)
+
+## "Later": more than first-time-only
+
+(The below only works if you let go of the idea that the only way you get volume-based alerts is when some unmute-condition occurs).
+
+Rather than just having first-time only rules, you could have alerting rules that are triggered when a condition
+persists. e.g.
+
+* Any time more than 5 events occur the past 3 hours (ignoring any events that occured before the last time this was
+  triggered). 
+
+## Personal Notification Settings
+
+Personal notification settings exist both globally (i.e. configured per User) and per Project. 
+
+Reasons for per-project settings include scenarios where someone is involved in the project but not to the extent of
+needing constant updates (e.g., consulting members or certain leads). 
+
+However, these settings are limited to a single toggle: yes/no/(default). That is, you can't choose specific rules to
+follow for a project (e.g. just on unmute, or just on regressions)
+
+More detailed configuration of alerting rules is project-centered. The idea is that the 2 main variables that control
+when alerts should be sent are dictated by the nature of the project, not the preferences of the member, namely:
+
+* how broken the project is (how many errors are generated)
+* how important brokenness is
+
+I.e. there is a single (configurable) threshold per project for what constitues "worth alerting about but avoiding
+swamping in false positives" which you can then subscribe to or not.
+
+(Note that the thoughts in this section are already less necessary to make explicit, because most of the volume-based
+alerting has (for now) been chosen not to implement in favor of vbc-unmute-rules (which are by definition not per user)
+
+## Chat-Ops
+
+You may configure any number of chat-ops endpoints (mattermost/slack channels). These are not connected to individual
+users. There's likely a default setting at the organization level. But it's also well imaginable that some project-based
+settings are necessary, e.g. when each project has its own channel.
+
+The chat-ops channels always receive the per-project configured set of notifications, i.e. the threshold cannot be
+changed per chat-op-channel (as with users).

bugsink-0.1.12/DESIGN-breadcrumbs.md

@@ -0,0 +1,5 @@
+Thoughts on breadcrumbs
+
+I think it is only a moderately useful functionality; it seems like an idea they once had, but which was never _really_ followed through on. Perhaps you as a user can make it more useful by making more aggressive choices on the client side. But how to (e.g.) disable it in the Django Integration is not easy to find, and disabling useless things is always important if you really want to take something in hand.  What happens with the logging integration is something I still have to read up. i.e. do certain logs just always become breadcrumbs? and how does that relate to logs that are automatically translated into events? (also read what I wrote about this in sentry-stfu)
+
+ And all those types and categories are only half thought through and defined, at least as far as the documentation is concerned. If I want to show such images it is a bit of reverse engineering (in combination with RTFM). It could be that in the JavaScript world, and combined with transactions, there is something more useful. I should see that then. As with log messages: we need some support for it, because the clients support this.

bugsink-0.1.12/DESIGN-connections.md

@@ -0,0 +1,76 @@
+Connection closing and subsequent re-opening is not free. I've done some experiments; it looks like the connection
+close/open themselves are in the sub-1ms range.
+
+But: when being the first connection to write, there is a c. 13ms penalty. Hypothesis: the opening of the WAL file.
+
+This is the code I played with to establish this.
+Note that the result of running the second half (the Django part) without first running the first half are very
+different from doing them both at once. Hence "being the first connection", i.e. there's a cross-connection effect.
+
+```
+from performance.context_managers import time_it
+import sqlite3
+
+conn = sqlite3.connect('db.sqlite3')
+cursor = conn.cursor()
+
+with time_it() as timings:
+  cursor.execute('UPDATE auth_user set username = username')
+  conn.commit()
+
+print("fresh conn", timings.took)
+
+with time_it() as timings:
+  cursor.execute('UPDATE auth_user set username = username')
+  conn.commit()
+
+print("reused conn", timings.took)
+
+
+from performance.context_managers import time_it
+import sqlite3
+from django.db import connection
+from django.db import models
+from users.models import User
+from performance.context_managers import time_it
+from bugsink.transaction import immediate_atomic
+
+with time_it() as timings:
+    with immediate_atomic():
+        User.objects.update(username=models.F('username'))
+
+print("django fresh conn", timings.took)
+
+with time_it() as timings:
+    with immediate_atomic():
+        User.objects.update(username=models.F('username'))
+
+print("django reused conn", timings.took)
+```
+
+With just the second half:
+
+```
+...     with immediate_atomic():
+...         User.objects.update(username=models.F('username'))
+... 
+CONNECTION created /mnt/datacrypt/dev/bugsink/db.sqlite3 124812146634816 in 0ms MainThread
+      1.79ms BEGIN IMMEDIATE, A.K.A. get-write-lock ↴
+      0.69ms ABOUT TO END IMMEDIATE transaction' ↴
+     10.67ms END IMMEDIATE transaction' ↴
+>>> print("django fresh conn", timings.took)
+
+django fresh conn 13.312101364135742
+
+>>> 
+>>> with time_it() as timings:
+...     with immediate_atomic():
+...         User.objects.update(username=models.F('username'))
+... 
+      0.19ms BEGIN IMMEDIATE, A.K.A. get-write-lock ↴
+      0.35ms ABOUT TO END IMMEDIATE transaction' ↴
+      0.50ms END IMMEDIATE transaction' ↴
+>>> print("django reused conn", timings.took)
+
+django reused conn 0.9033679962158203
+```

bugsink-0.1.12/DESIGN-log-messages.md

@@ -0,0 +1,6 @@
+We support Logging as good as we can, because we've taken the approach of being compatible with Sentry clients, and those occassionally send Log messages. We don't want to be confusing in that case. Having said that:
+
+Bugsink is about Error handling, not about arbitrary logging. Looking at the competition (Sentry, GlicthTip), I don't think log messages show up particularly strong there: because the message is lifted to the main title element, and because there is barely any info to show (certainly no stacktrace), they are in fact more confusing than anything (we've at least taken a more explicit approach, of putting some general "Log Message" at the top, and showing the message where the exception messages are generally shown). Perhaps that logging shines when you see it through the lens of transactions (then again: perhaps not -- maybe they're just chasing the trend of "log everythign").
+
+One further question: I see a lot of "error" levels in the messages as sent with some quick tests... even when those messages had lower log-levels.
+

bugsink-0.1.12/DESIGN-orgs-teams.md

@@ -0,0 +1,18 @@
+Thoughts on Teams and Organizations
+
+Our approach doesn't incorporate a sentry-like model for "teams." Instead, individuals are either part of a project or
+not. Envisioned roles are:
+
+* read-only access
+* regular (allowing state changes to issues)
+* admin (with privileges to manage settings and memberships).
+
+Regarding organizations, the use cases are:
+
+* if you're employed at "big-co", it serves as a platform to establish your "bigger team," which could oversee multiple
+  see e.g. GitHub, GitLab, and CloudFoundry for comparison
+* when I develop hosted.bugsink.com, the "organization" is the natural unit a user will have access to or not.
+
+These organizations can serve as points for inherited permissions, as well as provide a systematic grouping of
+projects. Additionally, they serve as a central repository for inheritable settings, streamlining the management and
+configuration of multiple projects within a broader organizational context.

bugsink-0.1.12/DESIGN-performance.md

@@ -0,0 +1,76 @@
+## Some thoughts on performance
+
+### 18 July surprise
+
+In the last few days I've been observing 85/s requests ingestion. What has changed? No idea...
+
+### Thoughts after -wal cleanup (better connection closing)
+
+There seems to be a small drop in ingestion performance, to approx. 30/s events. Given that this was (in "Original
+thoughts") the max, this is fine (for the increased (presumed) stability). (Pre-wal-cleanup this was approx 40/s)
+
+If this becomes a problem, the thing to consider is "keeping threads, and associated connections, open in the foreman".
+
+### Thoughts after implementing eviction
+
+(See also contents of ./performance/stress-with-eviction/)
+
+* Surprise 1: 50 events/s (60% more than what I found below)
+* Surprise 2: in this config, I _am_ getting snappea backlog.
+
+### Original thoughts
+
+Now that we have playground.bugsink.com, I could get some real data on that system too.
+
+I suppose the most "interesting" finding is that the ~30/s events I can handle seem to be entirely limited by the
+(https?) nginx stack.
+
+This also means that, in this setup, snappea is able to deal with "postponed" work basically as fast as the frontend can
+deliver it, i.e. there is no actual backlog. Which raises some serious(?) questions about snappea in this setup.
+
+Some things I played with (more or less in order I did them):
+
+* try to remove the (physical) network from the equation by doing local-loopback
+* use compression (brotli) to avoid network overhead
+* compare with my local laptop
+* drop actual handling of the request, i.e. just do a `request.read(); return HttpResponse()`
+* remove nginx from the equation and just connect on `:8000`
+
+Some numbers:
+
+All measurements are with a 50k event. (NOTE: after removal of whitespace this is actually a 40k event)
+
+* Starting point is ~30/s. local to playground; actual (non-immediate) handling of events. varying number of gunicorn
+  and snappea workers doesn't seem to do much.
+
+* local loopback on playground.bugsink.com: ~21/s. i.e. it's slower. Presumably: the cost of running the stress test.
+
+* local loopback on playground.bugsink.com, but dropping the request on the floor: ~25/s.
+
+* compressing as brotli and doing local -> playgrond: ~18/s. Surprisingly the cost of unpacking is larger than the
+  advantage of having to deal with less data.
+
+* locally (laptop), I got to ~280/s with actual handling turned on. This is where I (slightly) outrun snappea.
+
+* locally with drop-to-floor I got to ~455/s. Noteworthy: this is not even twice as fast as the "real" (postponed)
+  handling. i.e. we're already close to our limits with that.
+
+* turning off nginx, local -> playground: 146/s. Noteworthy: this is the only thing on playground that helped me go
+  faster. But we don't actually want to recommend that, of course. Also: this is the only setup where I was able to
+  outrun snappea (for a short while). Note that tuning thread for gunicorn / stress-test matters here. (I used 25)
+
+* playground locally w/o nginx and w/ drop-to-floor: 400/s. Noteworthy: very close to what I get on my laptop.
+
+
+
+Some conclusions:
+
+* 30/s is still "a lot"; that's 2.5M/day or 77M/month, which is _more_ than the maximum Sentry allows you to select in
+  the pricing page. (50M maxes out at $5,795.50 prepaid per month)
+
+* Still, the above raises some questions on "is snappea worth it in this setup". Counterpoints (stability,
+  predictability, the fact that there may be other slow async things) still apply.
+
+* I never really got a chance to tune my setup. I did raise gunicorn workers to "enough to deal with the number of
+  threads" which was in the 16 - 32 range. But with snappea without a backlog the number of workers is not material to
+  the performance.

bugsink-0.1.12/DESIGN-process-model.md

@@ -0,0 +1,52 @@
+### Snappea
+
+I ditched Celery.
+
+Why? It needs a broker. And the broker is "yet another thing to set up". Moving parts are the enemy!
+There may still be a future scenario where celery is a choice one can make. I've kept the interface as similar to celery
+as I could, so I can have it swapped back in later if needed.
+
+Considered alternatives:
+
+* redislite w/ celery
+    this seems "risky", you're basically putting an unsupported part in the (already complicated) machine and hope for
+    the best.
+
+* huey with file or sqlite backend?
+    the documentation seems to steer one away from this.
+
+* "inside" gunicorn: this didn't seem straightforward at all. uvicorn/channels may be better ways forward, but again,
+  the docs are steering one away from this.
+
+For now I'm just running in always-eager mode to facilitate running debugserver. This will probably change at some point.
+
+
+
+Considered alternatives for the "waking up"
+
+Currently implemented using inotify.
+Main drawback: tie-in to Linux.
+
+However, the model of "just writing some unique file" is very simple to understand.
+And the division of labor regarding these files is also simple (the clients just put files there, the snappeaserver just cleans)
+And it's a nicely decoupled model too: if either server or client is temporarily gone, the messages are not lost/blocking ("postbox model")
+And it provides a potential path forward if we ever want to put everything (the messages themselves) in those files.
+
+* signals: abandoned, e.g. https://github.com/python/cpython/issues/118143 for the reason
+
+* SIGSTP / SIGCONT: abandoned, I couldn't get this work reliably with "many signals" either. Process hangs mysteriously.
+
+* busy loop with read-on-the-db: still a good candidate. However: the read on the DB is somewhere between .1ms and 1ms.
+  and appears to be CPU-intensive. This means that the sleep() in the loop becomes something to think about and
+  potentially even configure (boooh!). In particular, you get a trade-off between the latency of picking up the work,
+  and the CPU load of the busy loop, which may depend on the fastness of your platform. This is exactly the kind of
+  thinking that I want to take away from myusers (and myself).
+
+* Zero MQ: still a strong candidate. I like that it's not tying us to Linux. And it's still brokerless. However, half
+  way through reading its manual I decided implementing this myself would still be faster than understanding yet another
+  component. Also: TCP is basically implied, which is another point of questions (firewalls etc).
+
+* Python's multiprocessing.connection.Listener ... introduces pickling. Yuck!
+
+* A FIFO where we write bytes: it doesn't seem to be a good fit for more than a single writer.
+

bugsink-0.1.12/DESIGN.md

@@ -0,0 +1,86 @@
+## Goals
+
+* Simplicity
+* Stability: easy to deploy; deploy once, and then forget it.
+
+Not "feature rich"
+
+Get *notified* about *programming errors* (not: connection errors) as they occur.
+Enough *context* to solve these errors. 
+
+On-prem running is the expected default.
+
+They sent a monolith to catch a monolith.
+
+Flowing from desire for "stability":
+
+* quota-from-the-ground-up (because otherwise: accidental DDOS)
+* thinking about resource-usage from-the-ground-up.
+
+
+CLI-first
+
+proxying should be a primitive
+    i.e. local client should be similar to servers.
+    (passing events is natural)
+
+
+built from understood/known performance characteristics 
+
+
+Solve as much client-side as possible.
+
+What you care about: "issues", not "events"
+    * issue-grouping
+    * We don't make money per-issue, we don't want to know about re-occurrences (or we want to know only a little about them)
+
+
+How valuable is the data? do we care about throwing out info?
+    "not as valuable as a running system"
+    errors that you care about will likely re-occur.
+    still: it's nice to not lose information.
+
+
+Splitting the issue-database from the organizational database?
+    "maybe"
+        con: extra complexity
+        pro: these things have different backup/reproduction regimes
+            the issues (other than "resolution") can be reconstructed from  
+
+
+
+Event-based from the ground up.
+    because "duh"... this is a textbook event system
+    because stability: easier to reason about costs this way.
+    because easier to get performant: do your calculations incrementally (e.g. quota usage becomes a +=1 operation)
+
+
+
+TECHNICAL CHOICES:
+
+mysql v.s. postgres (v.s. sqlite): make an _informed_ decision
+
+
+
+NEXT UP
+
+Start building
+    motto: off the shelve and boring components, but with an architecture which takes replacability in mind
+
+    ingesting  first
+        as a simple Django app which dumps everything into a textfield (this is TSTTCPW)
+
+        this also allows for 
+
+    dogfooding becomes possible: 
+        turn on sentry-SDK and send issues your own way.
+
+    a bunch of example events are availabe in e.g. GlitchTip.
+
+install both GlitchTip and Sentry locally.
+    optie 1: met de aangeraden docker-compose
+    optie 2: the "developer" view (misschien beter als je pdb wilt kunnen doen??)
+
+
+NEXT READING SESSION: last OS version of sentry itself.
+

bugsink-0.1.12/Dockerfile

@@ -0,0 +1,37 @@
+ARG PYTHON_VERSION=3.12
+
+# Build image: non-slim, in particular to build the mysqlclient wheel
+FROM python:${PYTHON_VERSION} AS build
+
+ARG WHEEL_FILE=wheelfile-not-specified.whoops
+
+COPY dist/$WHEEL_FILE /wheels/
+RUN --mount=type=cache,target=/var/cache/buildkit/pip \
+    pip wheel --wheel-dir /wheels /wheels/${WHEEL_FILE} mysqlclient
+
+
+# Actual image (based on slim)
+FROM python:${PYTHON_VERSION}-slim
+
+# ARGs are not inherited from the build stage; https://stackoverflow.com/a/56748289/339144
+ARG WHEEL_FILE
+ENV PYTHONUNBUFFERED=1
+
+ENV PORT=8000
+
+WORKDIR /app
+
+# mysqlclient dependencies; needed here too, because the built wheel depends on .o files
+RUN apt update && apt install default-libmysqlclient-dev -y
+
+COPY --from=build /wheels /wheels
+RUN --mount=type=cache,target=/var/cache/buildkit/pip \
+    pip install --find-links /wheels --no-index /wheels/$WHEEL_FILE mysqlclient
+
+COPY bugsink/conf_templates/docker.py.template bugsink_conf.py
+
+RUN ["bugsink-manage", "migrate", "snappea", "--database=snappea"]
+
+EXPOSE $PORT
+
+CMD [ "monofy", "bugsink-manage", "check", "--deploy", "--fail-level", "WARNING", "&&", "bugsink-manage", "migrate", "&&", "gunicorn", "--bind=0.0.0.0:$PORT", "--workers=10", "--access-logfile", "-", "bugsink.wsgi", "|||", "bugsink-runsnappea"]

bugsink-0.1.12/Dockerfile.db

@@ -0,0 +1,7 @@
+FROM mysql
+
+ENV MYSQL_DATABASE=bugsink
+ENV MYSQL_USER=bugsink
+
+# Expose the default port
+EXPOSE 3306

bugsink-0.1.12/LICENSE

@@ -0,0 +1,47 @@
+With regard to the Bugsink Software:
+
+This software and associated documentation files (the "Software") may only be
+used under either of the following 2 conditions:
+
+1. In production, if you (and any entity that you represent) have agreed to,
+   and are in compliance with, the Bugsink Subscription Terms of Service,
+   available at TODO (the "Terms"), or other agreement governing the use of the
+   Software, as agreed by you and Bugsink B.V., and otherwise have a valid
+   Bugsink subscription for the correct number of users.
+
+OR
+
+2. In a non-production environment, for a single user, for the purpose of
+   evaluating the Software, provided that you are not using or have not used
+   the Software in a way that would violate the Terms.
+
+Subject to the foregoing condition, you are free to modify this Software,
+provided that you do not remove the copyright notice and the license notice and
+do not modify the code in a way that would conflict with the Terms.
+
+You are not granted any other rights beyond what is expressly stated herein.
+
+Subject to the foregoing, it is forbidden to copy, merge, publish, distribute,
+sublicense, and/or sell the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
+For all third party components incorporated into the Bugsink Software, those
+components are licensed under the original license provided by the owner of the
+applicable component:
+
+* The icons in SVG format, directly included in various html templates are from
+  Heroicons by Tailwind Labs, Inc. (MIT License)
+
+* The code in the 'sentry' directory is Copyright 2019 Sentry
+  (https://sentry.io) and individual contributors. (BSD 3-Clause License)
+
+* Your package manager (typically pip) will install additional third party
+  components upon installing Bugsink. Please refer to the license of the
+  respective component in your package manager's repository.