UI module owner
Daniel Berlin
dberlin at dberlin.org
Mon Jun 26 16:09:16 UTC 2006
timeless wrote:
> Because you wrongly assume that all Bugzillas are public.
>
>> Yes, this could be made a bit easier by something
>> like the current "bug moving" mechanism but less hacky. But I don't see
>> the need for bi-directional linking, given that we don't use it in other
>> analogous situations.
>
> The analogous situations actually do need it, again, there needs to be
> someone doing translations, and in fact, other Bugzilla or bug
> tracking people usually do. when we get a bug in GCC, we don't just
> file the entire bug report into GCC's Bugzilla, we reduce it and file
> a shorter bug about the specific problem. and then the person who
> files it acts as the gateway.
In turn, GCC bugzilla does the same thing for classpath and gmp bugs (IE
places where GCC is the consumer of some library).
As for the later point about upgrading bugzilla, they really are forks.
I have maintained many Bugzillae, and I have *never had a single
Bugzilla where all i had to do was change templates*.
Thus, I've *always* had to fork the code, and *always* had to do my own
version control on it. Some of this is just to implement solution to
bugs that rot in mozilla.org's Bugzilla system, awaiting review (cc list
merging on duplicate marking, etc), or nitpicking clearly sane design
decisions because someone isn't willing to accept that there may be more
than one good design for something.
The claim that "Bugzilla already works in its default configuration, and
can meet a lot of people's needs" shows a fundamental lack of
understanding of how Bugzilla is used.
The only people i've met who *ever* use Bugzilla in it's default
configuration are those who are using it very temporarily, and don't
want to "fuss with code to get it to work how I want". That's an exact
quote, btw. Note the use of the word "code". This is not a mistake. No
interesting customization people perform can be performed to Bugzilla
without modifying the *existing code*.
In short, timeless is exactly right. This is also why GCC Bugzilla does
not run tip. Because I don't have time to continually edit the schema
changes into our small schema changes, and then hack at the upgrade so
it works properly.
I keep hoping maybe someday certain personalities in Bugzilla will stop
bickering over useless bullshit and just get things done (see, e.g.,
whether a certain implementation strategy for custom fields scales to a
billion bugs or not). It's been 5 years though.
I watch with hope as bugzilla moves away from globals and whatnot, and
that work seems to progress fine. However, the fundamental
customization issues never seem to be solved.
A large organizational hint: The amount of process that is involved in
Bugzilla in general is not in line with the amount of code it is.
I gave up filing bug reports against Bugzilla when i saw the amount of
comment typo nitpicking that went on to people who produce patches.
More information about the developers
mailing list