06.10.2020, 20:32, "Yusuke Suzuki" <ysuz...@apple.com>: >> 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.
Do you think these people have sufficient motivation to flesh out proper bug reports? I guess they'll just dump the same couple of sentences they post in Twitter comments and go away. Pleasing ungrateful people isn't really a way to go, IMO. > >> 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. Don't you do the same with Radar already? > > -Yusuke > >> -- >> Regards, >> Konstantin -- Regards, Konstantin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
