GitHub doesn't allow for data import/export or report generation as much as I'd like to stick with the GitHub issue management, and other limitations that will be pushed as we grow in GitHub usage.
I agree on the Bugzilla maintenance, we're looking into the specific scopes there too. -----Original Message----- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan Justen Sent: Wednesday, February 10, 2016 4:01 PM To: Laszlo Ersek <ler...@redhat.com>; Leif Lindholm (Linaro address) <leif.lindh...@linaro.org>; Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: edk2-devel@lists.01.org Subject: Re: [edk2] Task: Issue Tracking System for Tianocore On 2016-02-10 15:08:16, Laszlo Ersek wrote: > 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? > As an user of GitHub, Bugzilla and Jira. Jira: No advantages over Bugzilla. Bigger, and slower than bugzilla. I think it tries to be flashier than bugzilla (and bugzilla is admittedly a bit dated looking). Bugzilla: Works fine. Pain in the but to administer. You have to pay for hosting. GitHub: Easy, but simplistic. I think GitHub is the easier choice, and is good enough. Users will likely expect to find it used since the source is currently hosted there. Actually, we are currently using GitHub, so we would be talking about a change if we moved to anything else. We have 17 open and 18 closed bugs currently which far surpasses the activity in the bug tracking 'trac' system that we had on sourceforge for several years. :) (And, I think the same for the collabnet hosted bugs before that.) I think bugzilla is an okay choice if it can be paid for (with several years of funding...). I guess I'd recommend finding a service dedicated to hosting bugzilla, and not try to set up a server and self-host. It'd be a little annoying to have a separate bug tracker account. My vote is to stick with GitHub for now. -Jordan > > > > > -----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 _______________________________________________ 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
