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: >> 05.10.2020, 23:41, "Yusuke Suzuki" <ysuz...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
