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

Reply via email to