BMO/new-product

New Product

Creating a Product

Verify that requirements have been met. Often people will just do the top level stuff, and not include stuff like components

which have additional requirements.

All products should have a "General" component as a catch-all. the guided bug entry form looks for that component

Note: A product with a single component is suspect. In many cases the user may be perfectly happy with a component with an existing product. Check for other products that may be suitable and needinfo the reporter with suggestions. ask around on #bteam if you're not sure. An exception to this is if every bug filed under a product is something that should only be seen by a specific group, it makes sense to do a single-component product.

Each product needs at least one milestone and version

Use a default milestone of '---' and version of 'unspecified' if the requester says they don't need them

Default CC'ing on components is frowned upon, they should use component watching instead. this makes things much easier for everyone when someone leaves mozilla employment

Default assignee for components should almost always be nobody@mozilla.org

If they ask for the default QA to be nobody@mozilla.org, they actually want an empty as the qa contact default

If in doubt, needinfo the requester.

Use the admin --> products page to create the product

Check the default values from the requesting_changes wiki page, as they are different from the defaults in bugzilla

create the product initially as 'closed for bug entry'. uncheck this once everything's done

as right now code changes are required to set the product's default security group, the product won't be completely configured until the next code push. the only side effect of this is the default security group for bugs will core-security

https://bugzilla.mozilla.org/page.cgi?id=product_security_report.html does a sanity check

create versions, and milestones

Creating Components

Component watching requires a watch user. Rather than creating a new user, perform a user search (link) for and rename a "reuse me" user to usually similar to <component>@<product>.bugs but look for other watch users if adding a component to an existing product.

Creating Security Groups

• Security groups are rarely granted explicitly into. Normally the groups membership is determined by inheritance from other groups.
• Most security groups have a related "-team" group that is used for actually granting people into. For example, noone is in the 'client-services-security' group directly. There is a 'client-services-security-team' group which is a member of the 'client-services-security' group. The individual users are placed directly into the 'client-services-security-team' group when needed. Therefore they get access to the other group as well through inheritance. Only the 'client-services-security' group should be actually visible on the bug report.
• If the group is to be used as the default security group for a product (ie. it will be used when the user checks "Many users could be harmed by this security problem: it should be kept hidden from the public until it is resolved"), it must be set to Shown/Shown.

The non-team group needs to be enabled for viewing for the product using editproducts.cgi. The -team group should be made a 'member' of the non-team group.

Adding Flags

https://bugzilla.mozilla.org/editflagtypes.cgi is painful to use, especially because it replaces hyphens with non-breaking ones so in-page searching doesn't work

generally this requires adding the product to an existing flag's visibility. this is a two step process, first POST to add it to the include list, another POST to commit the change. i've lost count of the number of times i've failed that because that page doesn't use javascript

never accidentally remove another product/component from the inclusions (will remove flags :( )