UI module owner

[Gervase Markham]

Daniel Berlin wrote:
> In fact, I know of an large bugzilla user (supporting about 40 products,
> with >100k bugs total) that just completely gave up on Bugzilla very
> very recently because they got tired of trying to support their own
> changes in the face of the code changes Bugzilla is currently going
> through.  Most of their changes consisted of what I have done for GCC:
> adding a few fields, removing a few fields, and the validation
> associated with this.

Adding and removing fields from bugs has always been hard. That's just
the way it is. It's a weakness of Bugzilla - fair enough.

> Other than that, they wanted to do nice ajax'y things, but the workflow
> and code of bugzilla just doesn't give you the necessary hooks to do
> this without hacking up every source file in sight.

We have a hooks mechanism exactly for this - did they ask for any? Or
put in their own, for that matter?

> Given all this, they just decided to put a couple engineers on the task
> of making a nice sane bug tracker, and surprisingly, in about 2 man
> years, they have *done just that*.

2 man years? They couldn't have fixed their problems by putting those
people to work full time on Bugzilla for less than that long?

>> Which changes did you most commonly have to make?
> 
> Let's see:
> 
> Exposing any new variable to the bugs templates requires changing the code.

How would you have it work otherwise? I agree with timeless that there
are a couple (user, bug) which should always be there.

> Hiding a field that Bugzilla believes is required but is useless to your
> installation requires hacking up the edit script and the templates.

Actually, it only requires hacking the templates. But we should probably
fix that.

> Adding any sort of validation routines for some of the more freeform
> fields requires hacking up post_bug.cgi, the templates, the error list,
> the xml importer, etc.

Well, any scheme would require hacking in at least two places, because
you'd need a Perl version and a JavaScript version.

Are you talking about freeform fields still used for their originally
defined purpose, or ones you have repurposed?

> The problem isn't even that I have to write code, it's that i have to
> hack up the standard source files to do it, and I should not have to,
> because then i have to maintain these hacks as the source files change
> and move.

Have you discovered the template hooks mechanism? You can insert code
into any place in any template with a single added line.

> As a side note, I've actually always been surprised that bugzilla has no
> transaction objects, considering that things either look really ugly, or
> are just broke, if the database is left half-modified. IE bugs with no
> initial comment, etc.  Why the process of modifying a bug in some
> manner, from beginning to end, for a single request that may change the
> bug, the duplicates list, and the comments, is not encapsulated in some
> transaction object is beyond me.

I believe that getting rid of our old SQL stuff (just done this week, I
believe) is a prerequisite for this sort of thing. I think also MySQL
didn't support transactions until recently. But I could be wrong.

> But back to the topic at hand: half the time in changing this stuff
> between versions is figuring out where the code moved, then just
> rewriting it to whatever the new style of the day is for that code.  It
> doesn't really do anything different, it just seems to have changed
> coding style because someone felt it looked cleaner (again I'm *not*
> talking about the obviously necessary changes for mod_perl'ification,
> like removing globals, etc).

Can you give a concrete example?

>> If so, I'd be interested to know why bug entry templates, the format
>> system, the skin system, the custom templates system and the hooks
>> system are all not useful? Did we solve all the wrong problems?
> 
> Mostly, yes.
> The only templates people I know change are maybe the front template,
> and whatever is required to hide or move around some field.

So most of your customisations are Perl customisations?

Gerv