[webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

06.10.2020, 18:03, "Michael Catanzaro" <mcatanzaro at gnome.org>:
> 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).

FWIW, KDE is using Bugzilla for bug reporting, and Debian uses debbugs.

> 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.

This is certainly non-representative, but among the projects /me personally 
have interacted recently almost all use GitHub Issues, Bugzilla, or JIRA for
bug reports.

>
>>  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.

So, while you don't forward issues yourself, there is an intermediate
triage step which separates issues of browser applications and underlying
engine.

BTW, could you estimate how many of users which have provided
meaningful bug reports were directed to bugs.webkit.org but never made it?

-- 
Regards,
Konstantin