Plugins product
timeless
This should enable better cooperation with plugin vendors as well as
better tracking of interactions between mozilla and plugins.
For plugin vendors, I'd like to explain a bit about how this can be
used to your advantage.
Each component in Plugins has its own "watchable" qa contact. This
will enable someone working on a specific plugin to automatically
receive mail for bugs relating to that plugin.
As an example, take Steven Michaud.
He'd load
https://bugzilla.mozilla.org/describecomponents.cgi?product=Plugins
And since he works on the Java Embedding Plugin, he'd scroll down to:
Java (Java Embedding Plugin) .... jep-...@plugins.bugs
...
that last item "jep-...@plugins.bugs" in the "Default QA Contact"
column is the watchable contact.
he'd copy it and then load:
https://bugzilla.mozilla.org/userprefs.cgi?tab=email#new_watched_by_you
At the bottom it says:
User Watching
...
Add users to my watch list (comma separated list): [_________________________]
he'd paste jep-...@plugins.bugs into that field and click "submit changes"
Once that's done, he'd start receiving bugmail according to his
preferences for the "QA Contact" indicated on that page.
I've filed bug 558096 with my draft proposal for versions and target
milestones. I'd welcome comments in the bug from plugin vendors:
https://bugzilla.mozilla.org/show_bug.cgi?id=558096
If a vendor would like to adjust the name or description of their
component, please file a bug in mozilla.org Bugzilla: Keywords &
Components, e.g. using this link:
https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Bugzilla:%20Keywords%20%26%20Components
Just indicate which component you're talking about and what changes
you'd like made.
Steven for instance specifically requested to be the default assignee
for bugs in his component and to change the name slightly.
Mike Beltzner
cheers,
mike
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
David E. Ross
What bug number is associated with this change? The
bugzilla.mozilla.org database is a key element within configuration
management and configuration change for Mozilla. I would hope that
proper CM and CC procedures would be followed for any changes in
bugzilla.mozilla.org itself.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. � 1997
timeless
> What bug number is associated with this change?
Frédéric Buclin
>> What bug number is associated with this change?
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=557770
So you filed this bug *after* you created the Plugins product and its
components, because I could see this product before the time indicated
by the creation timestamp of this bug.
LpSolit
Carsten Book - Tomcat
bugs/crashes for a specific plugin much easier (maybe also for the 3rd
party vendor) and more effective than having everything as before in one
big core:plugin component.
- Tomcat
Mike Beltzner
> i think the new change is a great idea and makes work like triaging bugs/crashes for a specific plugin much easier (maybe also for the 3rd party vendor) and more effective than having everything as before in one big core:plugin component.
I like the idea in principle, but do wonder what happens with problems in Firefox code as it relates to plugins. Do those stay in Core::Plug-Ins?
cheers,
mike
Johnny Stenback
> On 2010-04-08, at 2:14 PM, Carsten Book - Tomcat wrote:
>
>
IMO they should stay in Core::Plug-ins.
> cheers,
> mike
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
--
jst
Mike Beltzner
> IMO they should stay in Core::Plug-ins.
Currently the Component Description for Core::Plug-Ins reads:
Plug-ins allow 3rd parties to register a binary library to be called when data of a given mime type is encountered. The plug-in can layout and render the data.
Can we get a better guideline of when to file in this component vs in the Plug-Ins component? I do worry that we're going to see much more filing of bugs like "Flash doesn't work with IME" in Plugins::Flash when it should be in Core::Plug-Ins ... sadly, I think this means more components for jst to watch. Not a blocker, just want to make sure someone's tracking it.
(Did we try to think of other approaches here, like whiteboard conventions or keywords?)
cheers,
mike
Mike Connor
On 2010-04-08, at 2:28 PM, Mike Beltzner wrote:
> On 2010-04-08, at 2:25 PM, Johnny Stenback wrote:
>
>> IMO they should stay in Core::Plug-ins.
>
> Currently the Component Description for Core::Plug-Ins reads:
>
> Plug-ins allow 3rd parties to register a binary library to be called when data of a given mime type is encountered. The plug-in can layout and render the data.
>
> Can we get a better guideline of when to file in this component vs in the Plug-Ins component?
How about "Bugs in core Mozilla code that supports registering and using plug-ins. For bugs in specific plugins, please file those bugs under Plugins."?
> I do worry that we're going to see much more filing of bugs like "Flash doesn't work with IME" in Plugins::Flash when it should be in Core::Plug-Ins ... sadly, I think this means more components for jst to watch. Not a blocker, just want to make sure someone's tracking it.
As it's just subdividing the same (theoretically!) number of incoming bugs, I don't think it's likely to increase workload, we just need to make sure that whoever was watching incoming Core::Plug-ins bugs is also watching the new components. WRT watching more components, it's just a more complex query to see that same set of bugs, but as the tradeoff there are good and obvious ways to actually watch specific subsets now, which feels like a big win.
> (Did we try to think of other approaches here, like whiteboard conventions or keywords?)
I think any purely-metadata-based solution makes it harder to get people involved with specific plugins (i.e. Flash or Java people) engaged and watching bugs against their own products. It also lends itself better to differentiating between "bugs in our code" vs. "bugs in external code" which is sometimes unclear.
-- Mike
timeless
> On 2010-04-08, at 2:25 PM, Johnny Stenback wrote:
>
>> IMO they should stay in Core::Plug-ins.
That's my intent, absolutely. And while deporting bugs which don't
belong, I try very hard to leave the ones which do belong there. When
I notice mistakes, I put them back.
> Currently the Component Description for Core::Plug-Ins reads:
>
> Plug-ins allow 3rd parties to register a binary library to be called when data of a given mime type is encountered. The plug-in can layout and render the data.
>
> Can we get a better guideline of when to file in this component vs in the Plug-Ins component? I do worry that we're going to see much more filing of bugs like "Flash doesn't work with IME" in Plugins::Flash when it should be in Core::Plug-Ins ... sadly, I think this means more components for jst to watch. Not a blocker, just want to make sure someone's tracking it.
Yes. https://bugzilla.mozilla.org/show_bug.cgi?id=558141
> (Did we try to think of other approaches here, like whiteboard conventions or keywords?)
We've tried both, they've failed miserably, but I'll leave tomcat/bc
to comment on this.
Carsten Book - Tomcat
>> (Did we try to think of other approaches here, like whiteboard conventions or keywords?)
>
> We've tried both, they've failed miserably, but I'll leave tomcat/bc
> to comment on this.
We used [crashkill-outreach] and [crashkill-thirdparty] as whiteboard
recently. But i think this was only used by chofmann and others involved
into crashkill. Other than that i think (if a keyword was used anyway)
"crash" as keyword was used in this cases - so this new component makes
things easier.
Also i will watch also this new components to make sure nothing gets
missed when its a Firefox Problem.
- Tomcat
Carsten Book - Tomcat
>
> We've tried both, they've failed miserably, but I'll leave tomcat/bc
> to comment on this.
Mike Connor
On 2010-04-08, at 1:14 PM, David E. Ross wrote:
> What bug number is associated with this change? The
> bugzilla.mozilla.org database is a key element within configuration
> management and configuration change for Mozilla. I would hope that
> proper CM and CC procedures would be followed for any changes in
> bugzilla.mozilla.org itself.
I think we need to be _extremely_ careful to not impose significant bureaucracy here. I think the key is not "was there a bug?" or "was a formal process followed?" but "who cares about this set of bugs, and who will be affected by change?" and ensure that those people are in the loop on changes. Anything beyond that is likely to be more hindrance than help.
-- Mike
Bob Clary
> We've tried both, they've failed miserably, but I'll leave tomcat/bc
> to comment on this.
I've always been conflicted about filing bugs on external plugins due to
the confusion it causes and misunderstanding of our roles. While these
are not our bugs, our users experience them and we find them on regular
basis. Anything that helps the external plugin bugs get fixed is a win
for our users, for us and the external plugin developers.
Whiteboard solutions could possibly work with enough effort but I
believe timeless' approach is a good one and wish I had thought of it
long ago.
With the new Product/Components we can easily describe what to do with
crashes or other bugs in external plugins by pointing to Plugins.
We are already getting a number of crashes in Flash, and Quicktime from
our automated crash testing and this will only increase as we extend our
plugin coverage. This new product will allow us to quickly file and
forget external plugin bugs. With the appropriate outreach, external
plugin developers can watch their own component and hopefully benefit
from our discoveries. Having a watchable qa assignment is great for them.
We need to be careful not to zero-day our users by filing public bugs on
security issues with external plugins. While we do have some contacts,
it would be very beneficial to have a "sooper sekrit" list of contacts
we could cc to bugs we consider security sensitive. Does anyone already
have such a contact list that can be shared?
.bc
timeless
> We need to be careful not to zero-day our users by filing public bugs on
> security issues with external plugins. While we do have some contacts, it
> would be very beneficial to have a "sooper sekrit" list of contacts we could
> cc to bugs we consider security sensitive. Does anyone already have such a
> contact list that can be shared?
I'm hoping that we'll be able to grow this more easily now. We've had
a fairly hard time just getting normal contacts.
Right now, we only have gospel for general contacts with the various
plugin vendors, let alone for security issues.
It's fairly easy for us to maintain a bug with such information. We
have one for the sheriff password.
Actually, we have two choices, we could use a single bug (in
Plugins:Other), or we could have a bug per plugin (in the appropriate
component), where the assignee is the one we would cc as our contact.
In the latter model, when that assignee changes organizational roles,
the assignee reassigns the bug to a replacement.
And when someone needs to look up the bug, they just query:
product:Plugins
component:<>
group is equalto core-security
summary: vendor contact
they don't even have to read the bug, just copy the value from the
assignee field of the buglist output :)
Reed Loden
"David E. Ross" <nob...@nowhere.invalid> wrote:
> The bugzilla.mozilla.org database is a key element within configuration
> management and configuration change for Mozilla. I would hope that
> proper CM and CC procedures would be followed for any changes in
> bugzilla.mozilla.org itself.
What does "CM" and "CC" mean in this context?
~reed
--
Reed Loden - <re...@reedloden.com>
Boris Zbarsky
> On Thu, 08 Apr 2010 10:14:25 -0700
> "David E. Ross"<nob...@nowhere.invalid> wrote:
>
>> The bugzilla.mozilla.org database is a key element within configuration
>> management and configuration change for Mozilla. I would hope that
>> proper CM and CC procedures would be followed for any changes in
>> bugzilla.mozilla.org itself.
>
> What does "CM" and "CC" mean in this context?
"configuration management" and "configuration change".
-Boris