On 02/10/16 23:59, Mangefeste, Tony wrote: > 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.
I recall that Linaro uses JIRA: https://cards.linaro.org/ Oh wait, there seems to be a new URL (still JIRA): https://projects.linaro.org I am (was?) subscribed to a minimal set of CARDs only, in the first system; I don't have any real experience with JIRA. Ard, Leif, can you please share your thoughts? Thanks! Laszlo > > -----Original Message----- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, February 10, 2016 2:44 PM > To: Mangefeste, Tony <tony.mangefe...@intel.com> > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org> > 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 >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >> > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
