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

[Max Kanat-Alexander]

On Wed, 31 Oct 2007 11:46:41 -0700 "Benton, Kevin"
<kevin.benton at amd.com> wrote:
> replacing
> each with isactive, then updating the code so we don't have four
> different ways to deal with whether or not a field or value is active
> or obsolete.

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

> field schemes [snip]

	I already have code that does this. It may even get into 3.2.

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

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

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

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

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

	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.

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

	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 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
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.