On Tue, 2007-04-10 at 16:53 -0400, Luke Macken wrote: > On Tue, Apr 10, 2007 at 02:43:51PM -0400, Greg Dekoenigsberg wrote: > > You all know my thoughts on this -- but to recap: > > > > 1. Get engaged with the xmlrpc work that's going on in upstream bugzilla. > > Make sure it's good. That takes care of the transport layer. > > > > 2. Work to get OpenID support into upstream bugzilla. That takes care of > > the authentication layer. > > > > 3. Work on the web UI to implement the "send this bug to another instance > > of bugzilla". That takes care of the interface layer. > > > > That's the winning strategy, I think. The question is, who has the time > > to implement, or to oversee implementation? > > > > FWIW, I think it's pretty strategic, and a lot of these pieces are already > > happening, so it's probably a matter of someone doing a strong design > > exercise -- but my hands are full elsewhere. > > +1 > > Bugzilla hacker Max Kanat-Alexander has been offering to help us > maintain our own Bugzilla instance for a while now. Will would know > better than I, but from what I've heard there is internal resistance to > push forward with this due to the added overhead of having to deal with > yet *another* Bugzilla instance. > > If we implement what Greg mentioned above, the issue of dealing with > another Bugzilla instance essentially becomes irrelevant. I was against having another bugzilla on the grounds that Red Hat doesn't even have one full time bugzilla hacker (last time this came up. I don't know about now.) If we have some community members who are willing to maintain and hack on a fedora bugzilla then that changes my take on things. It would be great to have better bugzilla integration and if Fedora was part of driving development of that it would be even better. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board