[webkit-dev] WebKit Transition to Git

Tue Oct 6 16:05:56 PDT 2020

06.10.2020, 20:32, "Yusuke Suzuki" <ysuzuki at apple.com>:
>>  On Oct 5, 2020, at 5:13 PM, 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 :)
>>
>>  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).
>
> I don’t think this works. People in twitter etc. do not file a bug even if it is requested by us not because Bugzilla has technical difficulties, just because “This is not GitHub”.
> So, moving to GitLab / making Bugzilla easy do not solve the problem.
> I think GitHub is selected not because GitHub has XXX feature. This is because GitHub has significant popularity over the other services, and a lot of people are familiar to how GitHub works.

Do you think these people have sufficient motivation to flesh out proper bug reports? I guess they'll just dump the same couple of sentences they post in Twitter comments and go away. Pleasing ungrateful people isn't really a way to go, IMO.

>
>>  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.
>
> This means that we need to watch two issue trackers for all normal issues. I think this significantly regress the productivity.

Don't you do the same with Radar already?

>
> -Yusuke
>
>>  --
>>  Regards,
>>  Konstantin

-- 
Regards,
Konstantin