I've gone down the track of using Bugzilla as well. Aside from the massive list of pros listed below, gathering any other preference is welcomed. I have used Bugzilla, but never been a maintainer on it. We do have some resources lined up for management of Bugzilla, if needed, so that's not a barrier. Of course, the devil's in the details.
So in short, Bugzilla is top of my mind right now. I'm looking at other OSS projects and seeing what they use. If anyone here sees one not listed below or has an opinion that they care to express please do so. On the mobility view, I'll try to play around with that and see how it looks on my mobile devices. Welcome to real-time decision making, thought process spewing. -----Original Message----- From: Laszlo Ersek [mailto:[email protected]] Sent: Wednesday, February 10, 2016 2:44 PM To: Mangefeste, Tony <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [edk2] Task: Issue Tracking System for Tianocore On 02/10/16 22:45, Mangefeste, Tony wrote: > We need an issue tracking system for Tiano. > > The built-in issue tracking system that comes with GitHub isn't > sufficient to satisfy a key requirement. There needs to be support > for multiple Tianocore-related programs. I agree. The Bugzilla instance that Red Hat operates supports many pieces of metadata, and "product" and "component" are two key fields. I would find it useful if the metadata reflected even the edk2 module in question, at least for long-established modules (library instances and drivers). This would also enable fine-grained automatic assignment to a maintainer. > As you know Intel has a > system today that's internal to Intel where we track issues. That > does not meet the needs of the community. And to help improve > transparency, and better engage with the community I'm driving the > discussion and bring up of a bug tracking system. > > The goal is to have one operational by March 21, 2016 (WW13). We're > 6 weeks and counting from that deadline. I'm interested in community > feedback, gathering requirements, and feedback on proposals for which > system to use. - Launchpad <https://bugs.launchpad.net/> Cons: - proportional width font - forcefully reflows comments, even if it means breaking git commit hashes into several parts, breaking copy & paste on double-click - truncates long comments in the "full bug view". If you'd like to read a careful, detailed comment to end, you have to open the comment in isolation. And then you can't look at the other comments at the same time. - Github issue tracker <https://github.com/tianocore/edk2/issues> Pros: - some integration with the code repository (automatic highlighting of commit hashes, for example; link leads to commit when clicked) Cons: - social interaction oriented, with @person style "callouts" - doesn't support binary attachments - very basic, lacking metadata - bug data is held hostage, no way to mass-export it in an open format / schema - proportional width font, with MarkDown enabled by default (interferes with ASCII diagrams and code pasting) - lackluster integration with email (can't send updates of one's own bug actions) - unwieldy permalinks for comments, even from within other comments on the same bug - allows anyone to reedit their own posted comments (that's a negative, yes) - Bugzilla <https://bugzilla.redhat.com> <http://bugzilla.kernel.org/> <https://gcc.gnu.org/bugzilla/> <https://bugzilla.gnome.org/> Pros: - the gold standard for serious free and open source software - heavy local customization possible - splendid outgoing emails, including about your own actions; metadata changes rendered in simple ASCII tables - heaps of metadata - public and private bugs - public and private comments and attachments - access to any individual bug can be restricted to specific groups (partners, customers, security response team) - flags for release planning and stakeholder signoff - well defined and customizable bug states and transitions - monospace font for comments - simple permalinks (can be hand-constructed if you know the bug nr and comment nr you want to refer to) - no markup beyond simple highlighting (as links) of a few patterns, like "bug NNN", "comment ZZZ", and "bug PPP comment QQQ". - bug aliases (like CVE-2016-NNNNN) that are highlighted and resolved to their respective bug numbers - dependency tracking between bugs, displayable in a tree-like view as well - support for cloning bugs for other components and products - elaborate queries can be composed and saved - you can watch people, regardless on what bug they comment or work on - supposed to mass-export bug data in XML - ability to collapse and expand individual and all comments - comment-specific "reply" links prime a new comment with the comment being replied to *correctly quoted* - ability to CC yourself and *others* on bugs - feedback can be requested from specific people or groups by setting a conspicuous and *formal* NEEDINFO request on them --> triggers separate email. NEEDINFO remains set until requestee answers or is explicitly cleared. - all metadata changes are tracked with timestamps in-line with the comments - comments are read-only once posted, unless special privileges are granted - textual template can be specified for all new bug reports - ... Cons: - requires bug reporters to think first (oh wait, that's a pro) - HTTP request/response oriented, only minimally AJAX-y (oh wait, that's a pro too!) - occasionally slow - requires serious, dedicated maintenance and/or perf tuning > > We're going to transform issue tracking on Tianocore a transparent, community > driven behavior. > > Key requirements for the system include (but not limited to): > * OSS (does not have to be free) > * Ability to bulk import/export databases, data (CSV) I agree; hopefully in something better than CSV (json or xml) > * Secure, ability to shield sensitive issues +1 > * Group credential management +1 > * Supports mobile views (phone/tablet) Not personally interested, but I agree it is important for many users today. Not sure how bugzilla performs in that regard. > * Ability to generate reports Yes. I *think* bugzilla supports reports, I'm just not using them (based on my position). > * Can be used to generate quick tasks for community members (e.g. Find > a Task) Hm. Never had this problem. ;) > * Integrate with GitHub What do you mean by this? Files and commits can be linked in any bug tracker simply by pasting the right URL. Automatic status changes for bugs when they are mentioned in commit messages (such as Fixes: ...) are counter-intuitive in my opinion. Personally I like to do this manually (add the commit references and close the bug). I realize others might think differently. > I appreciate anyone's time and passion on this. Let me know if you want to > participate in such a task force. No lack of passion here. :) OTOH, time to spend on a task force... I can't promise that. My general suggestion would be to steal what already works for large projects with distributed development. Thanks! Laszlo > > BRs, > Tony > > > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
