UI module owner

[timeless]

I wrote:
> Bugzilla should ship such that most companies don't feel the need to
> implement dozens of horrible hacks that cause them to refuse to
> upgrade to a newer version of Bugzilla later.

On 6/26/06, Gervase Markham <gerv at mozilla.org> wrote:
> Gregg completely agrees with you.
> http://wiki.mozilla.org/Bugzilla:Personas:Gregg

I'm glad I'm not alone, but I really don't care. I know I'm not alone.

gerv wrote:
> (BTW, everyone, the personas are still works in progress. Let me do a
> bit more work before you lay into them :-))

As I said, I already laid into them, they're bad and I'm not going to
spend my time helping you prop up something which I know doesn't work.

> How likely do you think it is that these different
> companies/organisations requirements will be similar enough that all the
> Bugzillas will be "fairly standard"?

I've used a number of Bugzillas, most of the changes are fairly
similar. I think it's fairly safe, as long as you accept some other
bits which I'm proposing in a blog entry which I'm *not* writing
because I'm *wasting* time writing this email.

As I've said before, your personas don't work and it's a waste of my
time to support them. they don't work.

> Observation: even if we have "get as many people as possible using it"
> as a goal, that doesn't by itself imply that moving bugs from one
> Bugzilla to another, or linking them together, is a requirement.

That's nice of you to think.

> Given that your aim is to have lots of people using Bugzilla in a
> standard way, which makes it easy to just grab an account and log in,
> why is the right solution to this problem just "move the bug
> across/refile it, and have interested parties track it in the other
> Bugzilla"?

I can't log into corporate Bugzillas. I can't log into bugs.opera or
Bugscape, I can't log into the Mozilla Foundation Partner Products
Bugzilla, we can't log into Cenzic's Bugzilla, you can't log into the
Bugzilla where I work.

> Let's look analogous situations. If a user files a bug, and it turns out
> that it's a duplicate of another one, do we "link them together and
> share comments"? No, we mark it as a dupe, it gets closed and the filer
> watches the other bug.

This is a mistake.

> If a user files a bug in the Firefox product, and it turns out that the
> problem is actually in the Core, do we open a core bug and link them
> together?

This is a mistake.

> No, we move the bug to the Core product, and have it fixed
> there - even if the bug report then becomes about fixing the underlying
> problem, rather than the particular symptoms the user sees.

This is a mistake. what actually happens is the end user starts
spamming the core bug. I've been proposing for a while switching to a
system where we split reports from bugs. end user Firefox items would
be reports. If you get a bug, you refile it as a dependency into core.
This avoids getting lots of bad comments from end users like "me too".
Yes it means that Firefox product would be responsible for having
gateway people (QA) who actually translate requests for more
information into the bugs reported by he end users. But it also means
that devs don't have to sit there explaining things. Just like I
shouldn't have to sit here repeating to you something i already wrote
in a blog.

> So why is it that we can't say that if someone files a bug in Mandrake's
> Bugzilla about their browser, and it turns out to be a bug in Firefox,
> we file a bug in b.m.o, close the Mandrake one and tell the users to
> watch the b.m.o. bug?

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.

The fact is you're absolutely out of touch with how Bugzillas are
used. which is why you shouldn't be doing any of the persona or
equivalent UI design.

> [There's also the issue that I suspect that it would be a real pain to
> implement, test and keep working, particularly when the Bugzilla
> versions start getting out of step, and after a few years when we've
> released four releases and the testing compatibility matrix starts
> getting larger and larger.]

This is discussed elsewhere. It's possible to manage. Note that there
are two forms of linking, one is a full link where you basically have
a foreign fields table for dealing w/ foreign bug trackers (Bugzilla
of other versions or any Bugzilla really being included here) which
has some provisions for trying to map fields.

> Firstly, you start out by using a perjorative word ("fork") to buttress
> your position, when what we are actually talking about is customisation,
> which can be more or less of a "fork" depending on the customisation
> mechanism used and the level of customisation required.

FWIW, it's pejorative, and Yes I am using it as such. And there's a
better way to do it which does not require code modifications, and
face it, our skins are code, so are our localizations.

Most customizations I've seen have resulted in people not upgrading.
Any time people don't upgrade, I consider this to be a fork. And yes,
I don't like it when people make customizations and then don't
upgrade.

> Secondly, you use over-generalisaion ("every single consumer") when
> quite clearly by observation, not every single consumer of Bugzilla
> makes significant customisations to it.

Just about every one I've ever used has. And I'm fairly certain that
it's safe to say must Bugzillas aren't running tip. yet if there were
no risks associated and no effort required, people should be willing
to upgrade and most people should be current. They aren't.

This is issue is addressed in the rant I'm not writing now because I'm
wasting time writing this message.

> Thirdly, you over-exaggerate ("just to make it work for them"); again
> clearly, by observation, Bugzilla already works in its default
> configuration, and can meet a lot of people's needs.

I'd like someone to name 5 Bugzillas where the people choosing the
Bugzilla said, "OK, we're going to use Bugzilla, because it's perfect,
there's not a single thing we'd want to change, there are no bugs in
it, there's nothing that we'd want fixed." If you're a Bugzilla
developer and you make any of those statements, you're smoking
something, because it means you don't know anything about the Bugzilla
bug database and its open bug list.

> OK... So what stops that feedback from ending up in
> bugzilla.mozilla.org?

This should be obvious

> And is there anything we can do about it?

Yes. But as everyone keeps reminding you, sticking any answers here is
feeding the troll which is a terrible idea.

> Then it might help not to call it skinning. The usual use of the word
> "skinning" (and the Bugzilla use - see the skins/ directory) is making
> graphical/cosmetic changes which do not have significant effects on the
> underlying functionality. For that, we have historically used
> "customisation".

It's not my fault, we don't have provisions for customizations. and by
the way, we don't write "customisation" we call it a customization
with a Z.

Please install and use a US English spellchecker (the one in minefield
should work quite nicely).

> Are you suggesting that we should fully integrate Mozilla-specific
> customisations into the stock Bugzilla, so they serve as better
> examples?

Yes. Note that specific browser pieces should be adapted so that
they're less specific.

FWIW, the Bugzilla I'm using internally has a URL field, and I
specifically deal w/ bugs about a web browser, but for some
incomprehensible reason people don't fill in the URL field! if the
customization was available and I could specify it for my product, I'd
be very happy to force it.