Bugzilla Contribution Process (was RE: New language discussion?)

[Max Kanat-Alexander]

On Fri, 2 Nov 2007 11:24:25 -0700 "Benton, Kevin"
<kevin.benton at amd.com> wrote:
> That's interesting.  Why have those fields then?

	When I originally wrote that patch, I was extremely new to
Bugzilla development, and I thought, "Oh, I'll just make them used in a
future patch." Long experience has now taught me that that doesn't
work, but those are left over as part of that error.

> his is the first
> I've heard of anyone else developing field schemes.  I haven't seen
> field schemes on a roadmap indicating that work was even being
> considered.

	It would be essentially implemented by:

	https://bugzilla.mozilla.org/show_bug.cgi?id=291433

	I do understand the difficulty of locating what's going on
sometimes.

> So are we for the purpose of general use, however, we need the
> denormalization to keep large volume queries operating relatively
> quickly.

	I wonder if they could be done just as quickly in the way Yahoo
does it, with UNIONed selects with simple WHERE clauses.

> The challenge from an administrative standpoint is anytime someone has
> to touch a template in order to change help, that's seen as a code
> change rather than a configuration change.  Maybe I'm out of date with
> what is happening with the help system, but it's my understanding at
> this point that changing help requires changing the template instead
> of data in the database.  I hope I'm wrong. :-)

	No, it requires changing a template. That's the only way to be
localizeable, currently.

> It's both an advantage and a disadvantage depending on perspective.
> We really want to contribute, but there is a real cost of
> contributing, just like there's a cost to fork (loss of ability to
> easily incorporate community updates).

	Sure. That's the exchange for the advantage of getting code
that other people have developed.

> I don't know how well that will fly with management - spend money to
> pay a contractor to incorporate something we're giving away into the
> community version...  Yes, I understand it has benefits, but I just
> don't know if I can sell it.  It's a valid option to consider,
> however. The question I will have to be able to answer in order to
> sell it is can we justify the cost considering the cost of the fork
> versus remaining much more in-sync...

	Yeah, I think that's a good equation. I can tell you that other
major corporations of a similar size to AMD have done it, and it's been
definitely beneficial to them. They no longer have to maintain that
code (we do it for them), which is a huge advantage as more and more
versions of Bugzilla are released.

> I agree with you with one addition - more *active* reviewers.  If I
> had more time, I'd be doing more reviews myself.  When there's a
> feature I'm interested in, I'm very likely to review.  I also do keep
> an eye on documentation reviews.

	That's good to hear, that you're keeping an eye on those
things. :-) Yes, more active reviewers would be great.

> Max - the work you've done to help Bugzilla move forward has been
> greatly appreciated, not just by us here at AMD, but I'm sure by
> others across many organizations.  The same is also appreciated of
> you on Fedora.  Open source would loose out if you didn't
> participate.  Thanks :-)

	Wow, thank YOU. :-) I'm totally smiling. :-) I'm touched.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.