> On 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. > > --- > > [1] Milestones are not issues themselves, but they establish true two-way > stateful relation between issues and their "parent" milestone. > [2] For some reason they have shared numbering, which means sometimes you may > not know what kind of reference is in front of you until you look up its URL > or navigate > > > 2. Sub-par issue categorization and search > ------------------------------------------------------ > > In traditional bug tracking systems every issue has properties like status, > resolution, component, severity/issue type, priority. When new bug is > created, user chooses values of these properties, which can be later adjusted > by the person doing triaging. They also are used in user-friendly search > dialog like [1]. > > All GitHub can offer here are custom labels. While in theory they are > sufficient to replace pre-defined issue properties, they require disciplined > use to be efficient, for example issue must not have mutually exclusive > labels. To avoid chaos, GitHub allows setting issue labels only to > contributors. However, this puts more work on triagers, and they cannot > triage only certain kinds of issues which match their interests by going > through results of search query. > > [1] https://bugs.webkit.org/query.cgi > > > 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 :) > > > Conclusion > -------------- > > You can say this is all small issues which are not really significant. With > current state of things when Bugzilla is mostly used as a code review tool, > and very few of issues reported by people who aren't WebKit developers get > any action, they indeed aren't showstoppers. But, AFAIU your goal is to > encourage more people to report feedback. If this plan works, a lot more > issue triaging will be needed, and these issues will become important. > > I guess it might be a better idea to start solving this problem from a > different end: start doing regular bug triaging of existing bugzilla issues. > If people see that their efforts to make a bug report were not in vain, they > might consider doing this again in the future. > > If you main interest is getting comments from W3C folks in the tracker > without sending them through account registration procedure, it should be > possible to allow them to create account through GitHub (if I understand > correctly, it should be possible to create "GitHub App" for our bugzilla with > access to user email, and automatically create new account based on that > email).
I don’t think this works. People in twitter etc. do not file a bug even if it is requested by us not because Bugzilla has technical difficulties, just because “This is not GitHub”. So, moving to GitLab / making Bugzilla easy do not solve the problem. I think GitHub is selected not because GitHub has XXX feature. This is because GitHub has significant popularity over the other services, and a lot of people are familiar to how GitHub works. > > Another thought: as WebKit is not actually user-facing product, it might be a > good idea to create GitHub issue tracker for e.g. Safari and collect user > feedback there. Some people may not understand the difference between browser > application and WebKit, and it won't be good if people start going to WebKit > issue tracker to submit feature requests for Safari just because they happen > to have GitHub account. And when issues are triaged, they can be resubmitted > to WebKit tracker by qualified person if they are really relevant. This means that we need to watch two issue trackers for all normal issues. I think this significantly regress the productivity. -Yusuke > > -- > Regards, > Konstantin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
