UI module owner

[Benton, Kevin]

... more follow-up from this email...

> timeless 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.
> 
> Gregg completely agrees with you.
> http://wiki.mozilla.org/Bugzilla:Personas:Gregg
> 
> (BTW, everyone, the personas are still works in progress. Let me do a
> bit more work before you lay into them :-))
> 
> > Bugzilla should be the standard tracking system that companies and
> > organizations use, so that when I have a problem with any product
> > anywhere, I can turn to a comfortable fairly standard Bugzilla
> > installation which I can easily log into, select my standard per
user
> > custom settings and feel right at home explaining my problem or
> > finding out the status of a preexisting report that I was able to
find
> > about my problem.
> 
> 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"?
> 
> Thought: none of the current personas use multiple Bugzillas. Does
that
> mean that this is a niche use, or that we've failed to capture
something
> in the existing persona set?

The later - I think we've failed to capture this in the existing persona
set.  I may be a typical admin/developer that did not install Bugzilla
initially for some AMD users, however, I continue to maintain it.  I
maintain a number of installations that I am still merging code on, and
I also use Bugzilla outside AMD (BMO, for example).

> > Bugzilla should enable any company to easily send a problem report
to
> > the next company or organization's Bugzilla without resorting to
> > hacks. Note that in almost all cases this communication is
> > bidirectional, it's not just a "move", it's some sort of "keep these
> > bugs in sync" or "share comments across bugs" or "establish a
> > dependency between these bugs". It's fairly rare for anything to be
a
> > simple "move" (the hack implemented for bugscape), most customers or
> > consumers appreciate at least being told "this is fixed in the next
> > version" and "the next version shipped with this fixed, you can
> > actually download it now", which are things you don't get if you
just
> > "move" a bug.
> 
> 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.

I think that linking to a foreign Bugzilla installation is a reasonable
requirement.  I have a Bugzilla product on one of my installations here
that is used to track Bugzilla in general as well as customizations
related to Bugzilla here inside AMD.  It's helpful to be able to resolve
my local bug 12345 is a duplicate of BMO bug 4214657.  That's not
currently possible using distributed code.

> 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"?

A bug in the distributed code needs to be fixed and usually benefits
everyone including the one reporting it or tracking it if it's fixed
there.  Initially, it'll be reported in the local installation, then
filtered up to BMO (assuming I take the time to re-file it there and
verify it's really a distributed code issue and not a local
customization). 

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

Actually, it doesn't get closed, it gets resolved as a duplicate.
Inside AMD, it doesn't get closed till the installation(s) it impacts
have been verified as fixed.

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

That's true because Firefox also belongs to Mozilla.  The problem with
my situation is that I may have intellectual property (IP) that I can't
release to MF in my bug, so I have to create a duplicate on BMO then
link my local bug to it.

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

IP rights may prevent us from doing that.

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

---
Kevin Benton
Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator
AMD - ECSD Software Validation and Tools
 
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.