On 03/10/16 11:58, David Woodhouse wrote: > On Thu, 2016-03-10 at 11:33 +0100, Laszlo Ersek wrote: >> >>> * Considering tying the Bugzilla login to GitHub using GitHub as the >>> provider. This would mean that anyone wishing to submit an item into >>> BZ would require a GitHub account. >> >> I vote against this. I find 3rd party authentication providers insecure. > > I concur. > > The end goal should be a coherent bug tracking system where a user can > file a bug, and it can be reassigned to TianoCore or to a specific > vendor's "value subtract",
I think a cross-vendor tracker is too steep. Usually vendors (including Red Hat) have their own public trackers already. For example, in Red Hat Bugzilla you can report bugs for (downstream) OVMF today. In Red Hat Bugzilla, bugs reported for downstream components that need upstream fixes first are handled in two three ways: - Sometimes the community decides to use Red Hat Bugzilla for upstream tracking. (Example: libvirt.) In this case, RHBZ receives two bugs: one for upstream, one for downstream. One is usually a clone of the other (within a single BZ instance, you can clone bugs, and their dependencies are set up automatically). They are also reported for separate products. - If the upstream project has an independent tracker, then RHBZ offers metadata fields for linking the upstream tracker entry. It even has some ingrained knowledge about specific high-profile upstream trackers (FreeDesktop.org Bugzilla, GCC Bugzilla, Kernel Bugzilla, and so on.) - If the upstream project lacks a tracker completely, then the important upstream mailing list threads are linked as comments in the RHBZ entry (problem report message, patch submissions, and so on). The hashes of the commits that fix the issue are also captured in a comment. (If the upstream project has its own tracker, then the hashes are (should be) listed there.) > and its *whole* lifetime can be tracked > until a fix is released for the specific instance that the user has > reported it with. > > For that, we *are* going to need the thing to live under the auspices > of the UEFI Forum, and we are going to need to be able to mark things > as private — using an account system that is *directly* under our > control. I don't think I'd be permitted to store data (private comments, for example) related to product planning in an external tracker. Product planning and many other managerial workflows can depend on bug metadata that are specific to a company or a department. I think a cross-vendor tracker is too much; my vote is an upstream-only tracker. > Sure, actually getting vendor buy-in for that is a completely different > story. But let's not design the system to make it hard :) I couldn't buy in. Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
