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.

When in doubt, needinfo the requestor.

The guided bug entry form requires that all product have a "General" component as a catch-all.

Each product needs at least one milestone (default: '---') and one version (default: 'unspecified')

Default CC lists are not used in most circumstances (See BMO/FAQ).

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

Use the edit product page to create the new product.

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

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.

Check the product security report for a sanity check

Creating Components

Component watching requires a watch user. Rather than creating a new user, perform a user search for and rename a "reuseme" user. The name should be in the form of <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 :( )