On Tue, Oct 6, 2020 at 3:13 am, Konstantin Tokarev <annu...@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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
