[webkit-dev] WebKit Transition to Git

[Michael Catanzaro]

On Tue, Oct 6, 2020 at 3:13 am, Konstantin Tokarev <annulen at yandex.ru> 
wrote:
> 1. Sub-par support for linking issues to each other
> ------------------------------------------------------------
> 
> Traditional bug tracking systems (like Bugzilla or JIRA) have support 
> of "related" or "linked" issues. Most important relations are
> 
> * A depends on B (B blocks A) - blockers and umbrella issues
> * B is duplicate of A
> * A and B are related in other unspecified way

GitHub does have duplicates btw, but the syntax is completely different 
from GitLab so I can never remember how it's done. It's not exposed in 
the UI. In GitLab it's easy: /duplicate #245 to mark a bug as duplicate 
of issue #245. (You can have cross-repo duplicates too, and I think 
even cross-*project* duplicates. This is very important for GNOME, but 
not for WebKit since WebKit is just one huge repo.)

I found instructions for GitHub here: 
https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/about-duplicate-issues-and-pull-requests#marking-duplicates

> * There is no easily visible list of relations: if you are not 
> closely following all activity on A, to find all issues related to it 
> you have to browse through all its (pseudo-)comments, which in some 
> cases might be long.
> * There is no *stateful* list of relations: if A was believed to have 
> common source with B, but then it was discovered they are not 
> related, you cannot delete relationship between A and B because there 
> is no relationship, just a set of comments.

In my experience, this isn't really a *huge* problem. Umbrella issues 
work well enough to track relationship between bugs, as do milestones, 
and you can use whichever you prefer. I admit it is not nearly as nice 
as Depends/Blocks from Bugzilla, though. But I think it should be good 
enough for us.

> * "#<number>" is not a safe reference format. Sometimes users' 
> comments may have other data in "#<number>" format with a different 
> meaning than references to GitHub issues. For example, may the force 
> be with you if someone pastes gdb or lldb backtrace into comment 
> without escaping it into markdown raw text block (```). Also, GitHub 
> parses mentions in git commit messages, so care must be taken to 
> avoid any occurrences of "#<number>" with a meaning different from 
> reference to issue number.

Yeah this is unfortunate and also guaranteed to happen. The first 
several dozen issues are going to be spammed with references to other 
bugs all over the place.

> [2] For some reason they have shared numbering, which means sometimes 
> you may not know what kind of reference is in front of you until you 
> look up its URL or navigate

This is silly too (and not a problem on GitLab, which uses # for issues 
and ! for merge requests). But although I agree it is a defect, is it 
really a huge problem? Probably not.

> Also, on test cases. You probably like this feature of Bugzilla when 
> you can attach self-contained HTML file to the issue and then simply 
> open it by URL in any browser including your build of WebKit to try 
> it out. Forget this - GitHub simply forbids HTML or JS attachments 
> (without wrapping them in archive):
> 
>     "We don’t support that file type. with a GIF, JPEG, JPG, PNG, 
> DOCX, GZ, LOG, PDF, PPTX, TXT, XLSX or ZIP."
> 
> And yes, take care not to use tar.xz or tar.bz2 or any other 
> unapproved archive type.

OK, now you've convinced me... this is bad. :P I forgot about this 
problem because GitLab does not have any such restrictions on 
attachments. It's very frustrating to have to say "I added a .txt file 
extension so I could upload this to GitHub. Please remove the file 
extension after you have downloaded the file before you use it." I 
would say this is strongest argument I've seen against GitHub. Silly 
problem to have tbh.

I'll just add that GitLab has become *really* popular for Linux-related 
projects. I have to regularly work with GNOME GitLab, freedesktop 
GitLab, and gitlab.com. Fedora and CentOS are both switching to GitLab 
too, so soon that will be five different public GitLab instances that I 
have to switch between regularly, and that's limited to only the public 
instances. Then there are also many major communities I don't work with 
that are also using GitLab (KDE, Debian, Purism). It's reached the 
point where unless you only work on Linux kernel itself, you probably 
spend a lot of time on one GitLab or another. It should be considered 
alongside GitHub as an option, especially if we're concerned about 
GitHub-specific problems.

> And when issues are triaged, they can be resubmitted to WebKit 
> tracker by qualified person if they are really relevant.

In practice, I don't think it's a good idea because (a) moving bugs 
upstream takes a lot of time, (b) it's quite often important to have 
the original reporter CCed on the issue and able to comment. I receive 
tons of WebKit bugs in the Epiphany bugtracker, and while a few years 
ago I might have forwarded reports upstream myself, nowadays I only 
provide instructions for reporting upstream. If the user takes the time 
to create a WebKit Bugzilla account, then we can continue in WebKit 
Bugzilla. Otherwise, the issue does not get fixed.

Michael