[webkit-dev] WebKit Transition to Git
annulen at yandex.ru
Tue Oct 6 02:56:09 PDT 2020
06.10.2020, 12:40, "Konstantin Tokarev" <annulen at yandex.ru>:
> 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:
>>> 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" ). 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 . 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.
>> 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.
More information about the webkit-dev