UI module owner

[Benton, Kevin]

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

In a for-profit situation, bi-directional links could create problems
with the inappropriate release of intellectual property, but that
shouldn't prevent companies from deciding to link bugs from one
installation to another within the company.

One could say that the fact that we display URLs in the comments should
suffice, but that doesn't set the link off enough.  If we were to
implement a URL field for each potential dependency, blocker, duplicate,
etc., then the problem would be solved.

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

I don't believe that would be an issue if we would simply implement a
hyperlink for "other" installation bug ID's.

> >> Clearly, it's not good to have only a few places using it - but we
are
> >> well past that stage.
> >
> > It's not good for every single consumer of this product to fork it
> > just to make it work for them.
> 
> The number of logical issues with that statement take my breath away.
> 
> 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.

Please don't make the assumption that we haven't forked.  AMD has made
enough customizations to the code itself that it really is a fork.
While we work hard to make our customizations parallel to the mainline,
it really isn't the same code.  In my mind, a customization is a small
set of changes that are easily maintained that generally only affect
what the user sees, not the underlying method of processing that
information.

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

Obviously, however, without empirical data, I believe that there enough
forks out there to at least consider what impact it will have.  I
believe it should be our goal to find out why others have forked and
find out if there are things we should be doing that make sense to
implement so those entities that have forked can re-join us in the main
code line.

> 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'm not looking at the original, but I can certainly say that there are
times when a requirement is just that - a requirement.  If a product
doesn't meet certain requirements, the product is unusable for the
potential customer's (user's) purpose.  Does that mean it can't be
adapted?  Generally, no.  Sometimes, however, the cost of adapting is
too great, thus making the product unusable to the customer.

> All in all, not a good start as a basis for arguing for a particular
> change.

It's not?  It seems to have gotten a good discussion going. :)

> >> Re-skinning an application (in the usual sense of the word "skin" -
> i.e.
> >> changing colours and logos) has no effect on TCO.
> >
> > The skinning we're interested in is more akin to guided, it's not
the
> > same as modern v. classic, it's the difference between advanced and
> > simplified.
> 
> 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 seems to me we need to decide on what terminology we're going to use
here.  I've seen fork, customization, and skinning.  Depending on the
user, each word has meant different things.

> >> > We just need a samples bundled in distro.
> >> They are.
> >
> > We have samples half bundled, we still have people asking how to
> > integrate things very much like the guided entry form, which if they
> > were fully integrated shouldn't happen.
> 
> The original rationale for the way they are bundled is that we wanted
to
> keep the distribution generic, rather than Mozilla-specific. So, we
said
> we would include the Mozilla-specific guided format as an example of
> what could be done, and put a big comment at the top saying "this is
an
> example".
> 
> Are you suggesting that we should fully integrate Mozilla-specific
> customisations into the stock Bugzilla, so they serve as better
> examples? (That might be a reasonable thing to suggest.) If not, what
> are you suggesting we change about the current method of bundling?

Why not?  It seems to me that the guided template method would appeal to
most admins and new users.

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