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. > 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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
