06.10.2020, 12:40, "Konstantin Tokarev" <annu...@yandex.ru>: > 06.10.2020, 11:42, "Ryosuke Niwa" <rn...@webkit.org>: >> On Mon, Oct 5, 2020 at 5:13 PM 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 >>> >>> 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.
Also it doesn't allow to create dependency tree with depth > 1, as children of milestone cannot be milestones themselves. -- Regards, Konstantin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev