On Mon, Sep 14, 2015 at 12:19:53PM -0700, Jordan Justen wrote: > Forwarded message from Laszlo Ersek (2015-09-14 03:57:01): > > On 09/12/15 01:06, Josh Triplett wrote: > > > On Fri, Sep 11, 2015 at 11:27:32PM +0200, Laszlo Ersek wrote: > > >> On 09/11/15 21:30, Josh Triplett wrote: > > >>> On a vaguely related note, what's the canonical place to report bugs in > > >>> OVMF? > > >> > > >> (Bugs? What bugs? :)) > > >> > > >> It's this list, <[email protected]>. > > > > > > There isn't a tracker of some kind? That's unfortunate. > > > > I won't disagree with you, but I'll note three things: > > > > (1) There isn't much use to a bug tracker if there aren't enough human > > resources to actually monitor that tracker, and work hard on the bugs. I > > can offer to monitor this list and work on bugs reported here the best I > > can. Bug fixing is hard and taxing; for *official* long-term bug > > tracking, some form of legal relationship is usually necessary. I do > > take my RHBZs very seriously. > > > > (2) OvmfPkg is one platform in edk2. I don't think OVMF / OvmfPkg should > > have its own separate tracker. And regarding a tracker for the entirety > > of edk2, there used to be one (still on sf.net), and nobody (no > > I think the bug tracker on sf got shut down when sf stopped supporting > their 'hosted services'. (Ie, for example, when they shut down the > hosted mediawiki service.) > > > contributor or maintainer) cared. Goto (1). > > > > (3) I've seen first hand how Fedora bug tracker entries, Debian bug > > tracker entries, and upstream QEMU bug tracker entries are handled. Goto > > (1). As I said, I try to do my best with bugs reported on the list, both > > in tracking them and in fixing them, as my load allows. > > > > > But thanks; I'll send mail to the list when we discover an issue while > > > experimenting with BITS. > > > > Yes, please do that. And thank you. In my experience, other package > > maintainers (not just us in OvmfPkg) are pretty responsive if you report > > bugs for their packages on the list, especially if you can narrow it > > down (bisection, good reproducer etc). > > > > > > > > (Also, if you don't intend to use github's issue tracker, you might want > > > to turn it off so people don't file things there and expect a response.) > > > > That's a very good point. Jordan, can you please disable the issue > > tracker on github? > > Well, there has been discussion on this topic at Intel. It is a > mentioned goal: > > http://www.tianocore.org/news/2015/05/01/UnderConst.html > > Some want to try to somehow run a bugzilla server. Personally, I think > the path of least resistence is to just use github's issues system. It > seems to go along with moving the source tree to git on github, and I > think their system works reasonably. > > I wish github had a better system for exporting the bug data. For > example, the wiki system is a clonable git tree, and it would be great > if the issues system worked the same way.
There are a few tools for extracting and continuously archiving the issue data. For instance, see https://github.com/joeyh/github-backup . _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
