1 028ccb39 2024-06-24 stsp = Bug Tracking =
3 028ccb39 2024-06-24 stsp A web interface where users and developers can store information
4 028ccb39 2024-06-24 stsp about bugs. Underlying storage should be in Git, such that anyone
5 028ccb39 2024-06-24 stsp can clone the repository, run a tool of ours (such as gotwebd?)
6 028ccb39 2024-06-24 stsp and read and modify issues. Ideally, a simple 'got send' of special
7 028ccb39 2024-06-24 stsp refs would be enough to update issue data in the main repository.
8 3524325c 2024-06-25 stsp Hence the storage format we use must be merge-conflict-free by design.
10 028ccb39 2024-06-24 stsp Blueprint for workflow of a good bug tracker using "user pain":
11 028ccb39 2024-06-24 stsp https://lostgarden.com/2008/05/20/improving-bug-triage-with-user-pain/
13 028ccb39 2024-06-24 stsp There is an unfortunate practice of overlaying bug tracking with feature
14 028ccb39 2024-06-24 stsp requests and milestones. Bugs and feature planning are often mixed, e.g.
15 028ccb39 2024-06-24 stsp in platforms like Trac and Redmine.
16 028ccb39 2024-06-24 stsp Ideally, bugs and feature milestones should be kept separate in a very
17 028ccb39 2024-06-24 stsp clear way, especially if we use the "user pain" approach.
18 028ccb39 2024-06-24 stsp We could have a project planning UI that manages TODO items and milestones,
19 028ccb39 2024-06-24 stsp separate from the bug tracker.
22 028ccb39 2024-06-24 stsp = Pull Requests and Code Review =
24 028ccb39 2024-06-24 stsp Some prior art:
26 028ccb39 2024-06-24 stsp Storing review comments:
28 028ccb39 2024-06-24 stsp https://github.com/google/git-appraise
29 028ccb39 2024-06-24 stsp https://github.com/google/git-pull-request-mirror
31 028ccb39 2024-06-24 stsp Storing PRs:
33 028ccb39 2024-06-24 stsp Github uses a trick where forks and pull requests don't actually use
34 028ccb39 2024-06-24 stsp separate repositories. Instead, they carve up the reference namespace
35 028ccb39 2024-06-24 stsp such that each fork has its own set of refs. But the underlying storage
36 028ccb39 2024-06-24 stsp is shared (greatly saving on disk space). We know this by word of mouth
37 028ccb39 2024-06-24 stsp and because of bugs like this one, where a tree from the youtube-dl
38 028ccb39 2024-06-24 stsp repository appears in the repository of DMCA takedowns:
39 028ccb39 2024-06-24 stsp https://github.com/github/dmca/tree/416da574ec0df3388f652e44f7fe71b1e3a4701f
41 028ccb39 2024-06-24 stsp We don't want such things to happen on gothub, so pull requests should use
42 028ccb39 2024-06-24 stsp dedicated repositories which contain just the branch that is being proposed,
43 028ccb39 2024-06-24 stsp including full history prior to this branch. This means PR storage will be
44 028ccb39 2024-06-24 stsp costly, but PR repositories can be designed to be temporary.
48 028ccb39 2024-06-24 stsp 1) alice clones bob.gothub.org/src.git to alice.gothub.org/src.git;
49 028ccb39 2024-06-24 stsp alice.gothub.org and bob.gothub.org are project spaces which can have
50 028ccb39 2024-06-24 stsp several committers each; however, we can expect some users will be using a
51 028ccb39 2024-06-24 stsp project space just for themselves, and in the PR context this can make sense
53 028ccb39 2024-06-24 stsp 2) alice creates a branch in alice.gothub.org/src.git and does some work.
54 028ccb39 2024-06-24 stsp When ready to send a PR, alice creates a dedicated repository at
55 3524325c 2024-06-25 stsp alice.gothub.org/foo.git and either provides anonymous read access or adds
56 028ccb39 2024-06-24 stsp read credentials such that bob can access foo.git (recall that gotd doesn't
57 028ccb39 2024-06-24 stsp support per-reference access rules, only per-repository rules);
58 028ccb39 2024-06-24 stsp alice can also add notification details for bob to be notified of changes
59 028ccb39 2024-06-24 stsp to foo.git via email, arbitrary notifications triggered by http/json (the
60 028ccb39 2024-06-24 stsp gothub site could provide portals to notification providers, e.g. pushover)
62 028ccb39 2024-06-24 stsp 3) bob can clone from alice.gothub.org/foo.git to obtain a copy of the changes:
63 028ccb39 2024-06-24 stsp bob receives notifications when alice sends changes to foo.git
65 028ccb39 2024-06-24 stsp 4) in bob.gothub.org/foo.git, bob can use a web UI to leave review comments
66 028ccb39 2024-06-24 stsp on diffs and/or the full files, on line-by-line granularity;
67 028ccb39 2024-06-24 stsp all data pertaining to code review is stored bob's repo within a dedicated
68 3524325c 2024-06-25 stsp reference namespace;
69 028ccb39 2024-06-24 stsp bob can add notification details for alice to be informed of code review
72 028ccb39 2024-06-24 stsp 5) alices can now react to review comments in two ways: leave comments at the
73 028ccb39 2024-06-24 stsp code review UI for bob.gothub.org/foo.git (needs some way of authentication);
74 028ccb39 2024-06-24 stsp make changes to code and/or branch history in alice.gothub.org/foo.git which
75 028ccb39 2024-06-24 stsp bob can then fetch again to repeat the cycle
77 028ccb39 2024-06-24 stsp 6) once bob is happy, bob.gothub.org/foo.git can be added as a temporary
78 028ccb39 2024-06-24 stsp remote of a clone from bob.gothub.org/src.git; bob fetches from foo.git,
79 028ccb39 2024-06-24 stsp rebases/integrates/merges the branch, and sends to bob.gothub.org/src.git;
80 028ccb39 2024-06-24 stsp optionally, code review comment history can be fetched from foo.git and
81 028ccb39 2024-06-24 stsp retained in src.git ; this step can be done manually by bob following
82 028ccb39 2024-06-24 stsp instructions, or it can be automated server-side
84 028ccb39 2024-06-24 stsp 7) alice.gothub.org/foo.git and bob.gothub.org/foo.git can be deleted
