On 2016-02-10 16:21:33, Mangefeste, Tony wrote: > GitHub doesn't allow for data import/export or report generation as
They have an API that should allow for this: https://developer.github.com/v3/issues/ > 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. > What other limitations? > I agree on the Bugzilla maintenance, we're looking into the specific > scopes there too. Can you confirm that a non-free (as in money) service will be funded for a substantial period of time? If we can pay someone reliable to run bugzilla for us, that would be nice. -Jordan > > -----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
