[webkit-dev] WebKit Transition to Git
mcatanzaro at gnome.org
Tue Oct 6 08:02:54 PDT 2020
On Tue, Oct 6, 2020 at 3:13 am, Konstantin Tokarev <annulen at yandex.ru>
> 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:
> * 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.
>  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
> 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.
More information about the webkit-dev