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

[Benton, Kevin]

> 	The only reason Bugzilla currently works that way is that
> isactive isn't used.

That's interesting.  Why have those fields then?

> 
> > field schemes [snip]
> 
> 	I already have code that does this. It may even get into 3.2.

This is one of the challenges of working with the open source community
in general.  With an in-house development team, we communicate to each
other on projects we're working on and nobody does anything "behind the
scenes" without communicating at least that it's being done to others
working on the project.  This 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.

> > For the purpose of searching, we've made some other 
> improvements such
> > as adding a bug_values_cache table that stores a bug_id, and the
> > values of many-to-many relationships for each bug (such as the CC
> > list members by email and dependency relationships).
> 
> 	See, funny, because we're actually re-writing things to
> eliminate those. :-

So are we for the purpose of general use, however, we need the
denormalization to keep large volume queries operating relatively
quickly.  Our expectation is to use triggers to update the
bug_values_cache table, though I know that doing it that way isn't
compatible with some of the databases Bugzilla supports currently (like
MySQL 4.1.x).  The speed decrease on the update end is worth the
dramatic speed increase on the search end.

> > We're also adding a description column to every table that doesn't
> > already have one for the purpose of improving the help system so it
> > can describe a table's values.
> 
> 	The help system was already improved to allow for adding help
> to any page. For us, we'd have to do this in a localizable way.

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. :-)

> > [snip] There are also times when we
> > feel we just can't wait for the community to review and approve what
> > we're doing.
> 
> 	And that's reasonable. That's one of the advantages of Open
> Source code.

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).

> > There are other pieces that we've developed that we
> > clearly want to see included, yet will take significant effort
> > because someone has to syncronize that code with the current tip.
> > [snip]
> 
> 	In that case, I'd recommend hiring a contractor to help you out
> with the process, somebody who's a core member of the Bugzilla team or
> a proven Bugzilla contributor. You might think this is a subtle
> self-advertisement, but it's not--there are many contractors, and I
> really do think this is a great way to give back to the community and
> also see your own goals realized.

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...

> > It's an issue to explain that we're dealing with forward
> > compatibility with Bugzilla.
> 
> 	I'd be happy to explain this to anybody who wants to talk about
> it.
> 
> 	I suspect that your managers don't understand the advantages of
> open source? That is, *somebody else*, who *doesn't work at your
> company*, is *also working on the code*. You get the work of many
> people for free.

Max - I agree that we get "stuff" for free, but we also have to consider
the value we need versus the value we may get based on a time line we
have no way to drive.  Yes, open source is a great way to go when that
source meets basic needs.

> 	The solid equation to look at, that any reasonable management
> will accept, is how much code you're getting for free versus how much
> work it takes you to synchronize with upstream. Given enough time,
> upstream will always win, because there's more people working 
> on it and
> we're adding far more new features than one person possibly could.

Yes, as long as upstream is going in the same direction as the needs of
the company, hence the reason for contributing back where appropriate or
forking if required (not preferred).

> > If there are things that this community can do to help improve
> > responsiveness by helping corporate contributors what kind of things
> > will help reviews get done faster (such as submitting full sets of
> > test cases and selenium test code to go with the developed code),
> > then I think you'll see more sponsored contributions coming.
> 
> 	Unfortunately the problem isn't limited to corporate
> contributions, or even large contributions. We simply need more
> reviewers. 

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.

> 	Even with more reviewers, patches must be of a reviewable size.
> I personally can edit down a patch to reasonable size at 2-3 hours
> maximum. (Usually it takes far less time.) If you don't have 2-3 hours
> to edit a patch, then you probably won't have time to revise 
> the patch,
> and as much as I'd like to be able to help, the solution to 
> that problem
> just logically doesn't lie with the Bugzilla Project.

I agree that having patches at a reviewable size is important to make
reviews go quickly.  From a purely business perspective, however, there
are times when justifying the extra time to get that code accepted is
difficult.  I understand, yes it does have benefits when accepted that
now the company doesn't have to maintain it any longer, however, at the
same time, there are no guarantees that a) it will be accepted, and b)
that the effort to make it acceptable is worth the risk to get it there.
This is especially true for large changes.

> 	I often don't read or respond to very long posts, but I read
> and responded to this one because the contribution process to Bugzilla
> is extremely important to me. I have already worked to make it
> easier and easier for new contributors to become known and contribute
> their work to the Bugzilla Project. If anybody has some reasonable
> ideas what can be done to further ease that process without relaxing
> our code quality standards, do please let me know, either here or by
> personal email.

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
:-)

Kevin

---


Kevin Benton
MySQL DBA #5739
Senior Software Developer
CAD Global Infrastructure Flow Services
Advanced Micro Devices
2950 E Harmony Rd
Fort Collins, CO  80528
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.