New b.m.o component for bugs caused by other software?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

New b.m.o component for bugs caused by other software?

majken@gmail.com
What with all the talk in the "incomplete" thread about siphoning off
invalid bugs, there is talk about adding something like "NOTOURBUG,"
but I'm wondering if that's what we really want to do.

Just like we move reports caused by poor site code to tech evangelism,
should we do the same for bugs caused by plugins, firewalls or other
"partner" software?  Surely we don't want to mark them INVALID and
then never bother with them again, especially as our numbers grow and
a bug in the flash plugin will effectively break Firefox for our
users.  Even if someone can't commit to hand-holding and pushing the
authors of the culprit software to a fix, at least it's open and
people can contact the authors to be sure they're aware of it and
someone can watch for a fix.

Am I on the right track?

-Majken "Lucy" Connor

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New b.m.o component for bugs caused by other software?

Nickolay Ponomarev
On 23 Apr 2007 00:31:08 -0700, [hidden email] <[hidden email]> wrote:
> a bug in the flash plugin will effectively break Firefox for our
> users.  Even if someone can't commit to hand-holding and pushing the
> authors of the culprit software to a fix, at least it's open and
> people can contact the authors to be sure they're aware of it and
> someone can watch for a fix.
>
At least for crashers in flash (and some other plugins) we sometimes
move the bug to Core:Plugins and CC the people from the company in
question. For the good, reproducible bugs it often leads to a fix in
the plugin code.

Without having contacts for the company in question and nobody being
responsible for dealing with these bugs, they are likely to just sit
there forever, just like bugs in Tech Evangelism do.

Nickolay
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New b.m.o component for bugs caused by other software?

majken@gmail.com
In reply to this post by majken@gmail.com
On Apr 23, 3:46 am, "Nickolay Ponomarev" <[hidden email]> wrote:

> On 23 Apr 2007 00:31:08 -0700, [hidden email] <[hidden email]> wrote:> a bug in the flash plugin will effectively break Firefox for our
> > users.  Even if someone can't commit to hand-holding and pushing the
> > authors of the culprit software to a fix, at least it's open and
> > people can contact the authors to be sure they're aware of it and
> > someone can watch for a fix.
>
> At least for crashers in flash (and some other plugins) we sometimes
> move the bug to Core:Plugins and CC the people from the company in
> question. For the good, reproducible bugs it often leads to a fix in
> the plugin code.
>
> Without having contacts for the company in question and nobody being
> responsible for dealing with these bugs, they are likely to just sit
> there forever, just like bugs in Tech Evangelism do.
>
> Nickolay

Yes, if we don't have contacts, but for a lot of these things we do,
or will in the near future.  At the very least we can make sure
they're filed in the partner app's bug tracking system.  I suppose
there will be cases where it's an infrequently used/unpopular program,
in those cases sure, but the ones I tend to see users experiencing
have to do with popular plugins or firewalls.  I'd just like to avoid
a case where someone files a bug caused by the skype plugin (for
example, since we had issues with that recently), it gets marked
invalid, and then the devs don't hear about it until weeks/months
later when enough users are hit by it. Especially if it's a product
that we have relations with/contacts for.  IMO it's preferable to seek
out contacts rather than simply mark as invalid, depending on the
scope of the issue.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New b.m.o component for bugs caused by other software?

Gervase Markham
In reply to this post by majken@gmail.com
[hidden email] wrote:
> What with all the talk in the "incomplete" thread about siphoning off
> invalid bugs, there is talk about adding something like "NOTOURBUG,"
> but I'm wondering if that's what we really want to do.

As a resolution or a status? It sounds like a resolution, but below you
refer to such bugs as still "open", which implies it might be a status.

> Just like we move reports caused by poor site code to tech evangelism,
> should we do the same for bugs caused by plugins, firewalls or other
> "partner" software?  Surely we don't want to mark them INVALID and
> then never bother with them again, especially as our numbers grow and
> a bug in the flash plugin will effectively break Firefox for our
> users.  Even if someone can't commit to hand-holding and pushing the
> authors of the culprit software to a fix, at least it's open and
> people can contact the authors to be sure they're aware of it and
> someone can watch for a fix.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New b.m.o component for bugs caused by other software?

Nickolay Ponomarev
On 4/23/07, Gervase Markham <[hidden email]> wrote:
> [hidden email] wrote:
> > What with all the talk in the "incomplete" thread about siphoning off
> > invalid bugs, there is talk about adding something like "NOTOURBUG,"
> > but I'm wondering if that's what we really want to do.
>
> As a resolution or a status? It sounds like a resolution, but below you
> refer to such bugs as still "open", which implies it might be a status.
>
That's because below Lucy suggests an alternative for this NOTOURBUG
resolution - creating a separate component for such bugs and keeping
them open (UNCO, NEW, whatever) there.

If we also make the triagers aware of that component and collect a
list of contacts for the major third-party products, this would allow
us tracking issues that affect large portion of our users as well as
help making the people who can fix the bug aware of it.

Nickolay
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New b.m.o component for bugs caused by other software?

Gervase Markham
In reply to this post by Gervase Markham
Nickolay Ponomarev wrote:
> That's because below Lucy suggests an alternative for this NOTOURBUG
> resolution - creating a separate component for such bugs and keeping
> them open (UNCO, NEW, whatever) there.

Ah, right :-) With you now.

Yes, I agree. We should have components for all third party products on
which we get significant misfiled bugs (Java plugin, Flash, etc.), move
bugs into there and try and make sure the organisations concerned know
about them. That's better than resolving the bug and saying "not our
problem".

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New b.m.o component for bugs caused by other software?

Nelson Bolyard
Gervase Markham wrote:

> Nickolay Ponomarev wrote:
>> That's because below Lucy suggests an alternative for this NOTOURBUG
>> resolution - creating a separate component for such bugs and keeping
>> them open (UNCO, NEW, whatever) there.
>
> Ah, right :-) With you now.
>
> Yes, I agree. We should have components for all third party products on
> which we get significant misfiled bugs (Java plugin, Flash, etc.), move
> bugs into there and try and make sure the organisations concerned know
> about them. That's better than resolving the bug and saying "not our
> problem".

So, every product is going to get N new components?

Take, for example, problems people have with a certain brand of IMAP server.
Bugs about that get filed against Thunderbird, against various components
of "core", and against NSS.  Are each of those products going to get a new
component for that brand of IMAP server?

Maybe what you want are new bugzilla "products" for the different third
party products.

Having said that, I'm torn about whether this is a good idea or not.

Bugs reports against mozilla products that are actually caused by third
party products (or sites) are like false accusations against the mozilla
products.  Over time, the presence of large numbers of them tends to
unfairly defame the mozilla products falsely accused.  People tend to
assume that if there were 100 bugs filed about this problem, it really
must have been a Thunderbird problem (for example).  So, I like the
idea of putting the blame where it belongs.

But I'm worried about increasing the number of duplicate bugs filed.
Will the users of a certain bad IMAP server (for example) search the
bugs against that server product for duplicates?  Or will they always
search for Thunderbird bugs instead.  If all the bugs caused by that
IMAP server get moved to another product, (or another component of the
"Core" product) then will any Thunderbird users ever find them?

Unfortunately, I think we have no way of knowing how many duplicate
bug reports are prevented by people finding duplicates first.  Maybe
that number is current SO LOW that this proposed change isn't going
to make duplicates significantly worse.  Or maybe TONS of duplicates
are being prevented, and this would hurt a lot.  Who knows?

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New b.m.o component for bugs caused by other software?

majken@gmail.com

>
> Unfortunately, I think we have no way of knowing how many duplicate
> bug reports are prevented by people finding duplicates first.  Maybe
> that number is current SO LOW that this proposed change isn't going
> to make duplicates significantly worse.  Or maybe TONS of duplicates
> are being prevented, and this would hurt a lot.  Who knows?

I think the people that will go into the advanced search and narrow
their search that way will learn to also check x other component. I
think for the most part, people that file dupes are doing the basic
search.  In theory this could be avoided by making the "partner
relations" (is that the right term for this?) bugs inside the product
component, I don't know if that's more or less desirable.

You also bring up a good point about open bugs.  Maybe we want to have
a resolution of "partnerbug" or some such, and then use keywords to
note when they're fixed by the partners.  In effect, still using
"notourbug" but also using the new component to track them.

I'm with Gerv that the popular providers should have a level of
disambiguation, so Product (Firefox) Component (Partner Software) and
then add Vendor (Flash).  Let the major software have their own Vendor
and group the smaller ones into Other.  Hmm although I guess we do
want to make it Component, because in theory, anything that is a
problem with Flash should be automatically assigned to the person on
our team that is the official contact to flash, etc.

-Majken

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New b.m.o component for bugs caused by other software?

Gervase Markham
In reply to this post by Nelson Bolyard
Nelson Bolyard wrote:
> So, every product is going to get N new components?

No; I'm not anticipating going overboard. I was thinking primarily of
one for Flash and one for Java. One would only want these for third
party products about which there were a significant number of bugs.

Product: Firefox, Components: Third Party: Adobe Flash, Third Party: Sun
Java, etc.

> Maybe what you want are new bugzilla "products" for the different third
> party products.

That would be a reasonable way of organising it.

> Bugs reports against mozilla products that are actually caused by third
> party products (or sites) are like false accusations against the mozilla
> products.  Over time, the presence of large numbers of them tends to
> unfairly defame the mozilla products falsely accused.  People tend to
> assume that if there were 100 bugs filed about this problem, it really
> must have been a Thunderbird problem (for example).  So, I like the
> idea of putting the blame where it belongs.

On the other hand, if they are all duped against a bug which clearly
states "this is not our fault", people are more likely to find that when
searching than if the bug is just marked INVALID.

> But I'm worried about increasing the number of duplicate bugs filed.
> Will the users of a certain bad IMAP server (for example) search the
> bugs against that server product for duplicates?  Or will they always
> search for Thunderbird bugs instead.  If all the bugs caused by that
> IMAP server get moved to another product, (or another component of the
> "Core" product) then will any Thunderbird users ever find them?

Fair point; this is a disadvantage of using another product.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New b.m.o component for bugs caused by other software?

Robert Kaiser
Gervase Markham schrieb:

> Nelson Bolyard wrote:
>> So, every product is going to get N new components?
>
> No; I'm not anticipating going overboard. I was thinking primarily of
> one for Flash and one for Java. One would only want these for third
> party products about which there were a significant number of bugs.
>
> Product: Firefox, Components: Third Party: Adobe Flash, Third Party: Sun
> Java, etc.
>
>> Maybe what you want are new bugzilla "products" for the different third
>> party products.
>
> That would be a reasonable way of organising it.

I actually think a single "Third Party" product with components for
those products would probably be enough - and sounds like the cleanest
solution to me...
We also can have an "other" component for bug where a separate
components for that third party product doesn't make sense, but we still
want to have this in the right bugzilla product.

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New b.m.o component for bugs caused by other software?

Nickolay Ponomarev
On 4/25/07, Robert Kaiser <[hidden email]> wrote:

> Gervase Markham schrieb:
> > Nelson Bolyard wrote:
> >> So, every product is going to get N new components?
> >
> > No; I'm not anticipating going overboard. I was thinking primarily of
> > one for Flash and one for Java. One would only want these for third
> > party products about which there were a significant number of bugs.
> >
> > Product: Firefox, Components: Third Party: Adobe Flash, Third Party: Sun
> > Java, etc.
> >
> >> Maybe what you want are new bugzilla "products" for the different third
> >> party products.
> >
> > That would be a reasonable way of organising it.
>
> I actually think a single "Third Party" product with components for
> those products would probably be enough - and sounds like the cleanest
> solution to me...
> We also can have an "other" component for bug where a separate
> components for that third party product doesn't make sense, but we still
> want to have this in the right bugzilla product.
>
Yes, this is how I envisioned this working when I said it was a good
idea. Pretty similar to how Tech Evangelism is organized. The summary
can be used to identify the specific third-party product and mozilla
product(s) it conflicts with, e.g.

"Flash v9.x.y - crashes on www.example.com [@ NPSWF32.dll]"
"SampleAntivirus v3 - erases bookmarks.html (Firefox, SeaMonkey)"

Nickolay
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New b.m.o component for bugs caused by other software?

Gervase Markham
In reply to this post by Robert Kaiser
Robert Kaiser wrote:
> I actually think a single "Third Party" product with components for
> those products would probably be enough - and sounds like the cleanest
> solution to me...

It is a clean solution, but the disadvantage is that it might well not
get searched when people are looking for their problem. We can mitigate
this a bit with defaults, perhaps.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning