[webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

06.10.2020, 11:42, "Ryosuke Niwa" <rniwa at webkit.org>:
> On Mon, 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.
>
> Yeah, this is a pretty significant functional regression to me. I use
> bug dependencies all the time (e.g.
> https://bugs.webkit.org/showdependencytree.cgi?id=148695&hide_resolved=1)
> and not having this capability will significantly hinder my ability to
> track & triage some bugs.

As I've mentioned above, for this particular case you could create a milestone "Implement v1 shadow DOM API" and add all subtasks to it. Then you have a list of dependencies in one place, with ability to see only unresolved once, and with a nice progress bar. But you may find this approach a bit lame, because milestone itself is not a proper task, it has nothing else but title, description, and due date. Also, it's probably wrong to call this entity a milestone.

>
>>  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 :)
>
> This is another massive functional regression. I open test cases on
> Bugzilla without downloading all the time, not to mention that it's a
> great way to test iOS devices as well. Not being able to do that would
> significantly reduce my productivity.
>
> - R. Niwa


-- 
Regards,
Konstantin