[webkit-dev] WebKit Transition to Git

Wed Oct 7 15:51:04 PDT 2020

Hi there,

There is one more annoyance I am adding below Konstantin's list…

On Tue, 06 Oct 2020 03:13:32 +0300 Konstantin Tokarev <annulen at yandex.ru>
wrote:

> 05.10.2020, 23:41, "Yusuke Suzuki" <ysuzuki at apple.com>:
> > I think security component is special in terms of how to handle it already
> > (e.g. not posting a test with the patch etc.) To me, handling non-security
> > issues in GitHub and security issues in Bugzilla is OK.  By nature,
> > security issues are not open. Since one of our motivation of moving to
> > GitHub is openness for feedback collection, security issue in Bugzilla
> > does not matter for this motivation.  Ideally, handling both in GitHub is
> > better. But to me, rather than continuing using Bugzilla, using GitHub for
> > non security issues sounds improvement.
> 
> To me it sounds as a huge step backwards. Asides from situation with
> security issues, it has other significant drawbacks in domain of issue
> triaging and management:
> 
> 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
> 
> All GitHub can offer here now is mentions (and, to some extent, milestones
> for case of "umbrella issues" [1]). Mention is created every time someone
> uses "#<number>" (e.g. "#123") in the text of issue or in the comment, where
> number is a sequential number of issue or pull request [2]. When comment is
> published in issue A which mentions issue B, there is a pseudo-comment added
> to B, and subscribers of B receive email notification.
> 
> At first glance this naive approach seems to work, but
> 
> * 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.
>
> * "#<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.
> 
> ---
> 
> [1] Milestones are not issues themselves, but they establish true two-way
> stateful relation between issues and their "parent" milestone.  [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
> 
> 
> 2. Sub-par issue categorization and search
> ------------------------------------------------------
> 
> In traditional bug tracking systems every issue has properties like status,
> resolution, component, severity/issue type, priority. When new bug is
> created, user chooses values of these properties, which can be later
> adjusted by the person doing triaging. They also are used in user-friendly
> search dialog like [1].
> 
> All GitHub can offer here are custom labels. While in theory they are
> sufficient to replace pre-defined issue properties, they require disciplined
> use to be efficient, for example issue must not have mutually exclusive
> labels. To avoid chaos, GitHub allows setting issue labels only to
> contributors. However, this puts more work on triagers, and they cannot
> triage only certain kinds of issues which match their interests by going
> through results of search query.
> 
> [1] https://bugs.webkit.org/query.cgi
> 
> 
> 3. Sub-par attachments
> ------------------------------
> 
> Traditional bug trackers allow attaching files to issue. GitHub goes further
> and allows to attach files to every comment. Enjoy the progress -  now you
> can look for attached test cases and proposed patches through all comment
> feed, instead of having them in one place at the top.
> 
> 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.
> 
> But you can attach funny cat picture to your comment and it will be
> displayed inline :)

4. Reviews/PRs are detached from their bugs
-----------------------------------------------

With our current setup in Bugzilla reviews end up generating a comment in
the bug itself. This keeps all the conversation related to the bug, its
fix, and the process to solve it all in the same place. OTOH, in GitHub
(same with GitLab) both pull requests and the bugs they fix can have
comments, which results in the conversation being split between the two
of them. I find it convenient and easier to follow to have everything
in one place.

It could be that having review comments alongside the rest of the bug is
something we will would end up losing anyway regardless of which Bugzilla
replacement is chosen…

> Conclusion
> --------------
> 
> You can say this is all small issues which are not really significant. With
> current state of things when Bugzilla is mostly used as a code review tool,
> and very few of issues reported by people who aren't WebKit developers get
> any action, they indeed aren't showstoppers. But, AFAIU your goal is to
> encourage more people to report feedback. If this plan works, a lot more
> issue triaging will be needed, and these issues will become important.
> 
> I guess it might be a better idea to start solving this problem from a
> different end: start doing regular bug triaging of existing bugzilla issues.
> If people see that their efforts to make a bug report were not in vain, they
> might consider doing this again in the future.
> 
> If you main interest is getting comments from W3C folks in the tracker
> without sending them through account registration procedure, it should be
> possible to allow them to create account through GitHub (if I understand
> correctly, it should be possible to create "GitHub App" for our bugzilla
> with access to user email, and automatically create new account based on
> that email).
> 
> Another thought: as WebKit is not actually user-facing product, it might be
> a good idea to create GitHub issue tracker for e.g. Safari and collect user
> feedback there. Some people may not understand the difference between
> browser application and WebKit, and it won't be good if people start going
> to WebKit issue tracker to submit feature requests for Safari just because
> they happen to have GitHub account. And when issues are triaged, they can be
> resubmitted to WebKit tracker by qualified person if they are really
> relevant.

The confusion between WebKitGTK and an user facing application (typically
Epiphany) is something that happens for us as well. When somebody observes
a problem with Epiphany, typically they do not even have the GTK MiniBrowser
installed which would have been useful to have an idea whether the issue is
in WebKitGTK, so when we don't know where something goes we even tell people
to report their issue in the Epiphany bug tracker and we may end up moving
them to the WebKit Bugzilla ourselves once we have had the chance to take
a look.

Cheers,
—Adrián
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20201008/c8e16c5f/attachment.bin>