qertbe.blogg.se - Bugzilla update

#Bugzilla update Patch#

A few of them require some special handling: (Sample: bug 286278)īasically, you just have to get all the bugs to have patches with review+ on them.

New Features Page (Release Candidates and Final Releases Only): Make this bug depend on the appropriate Release Notes bug.

For final releases of major versions, you need a "clean up release notes" bug. Each version being released needs a separate Release Notes bug filed.

Release Notes: Point releases and rc1 versions need release notes.

Security Advisory: It should block the first bug, and and Security bugs targeted at this release should be dependencies.

"Release Bugzilla X.YY, Z.AA" and mark it as severity "blocker." It should block bug 286269, which has the alias bz-release.

The version number will be determined at time of branching depending on the changes included, as per the section above. Bugs blocking release should be denoted with a blocking flag, e.g. If there are bugs related to new features in the release branch, the feature should be backed out of the release branch (if it's very recent), or fixes should be committed to both the release branch and master. Branching should be done when master is relatively stable, but sometimes branching with known bugs is acceptable if it allows other large, potentially unstable features to land (for the next release). We release approximately once per year with whatever is ready at the time.

#Bugzilla update Patch#

We may also occasionally release a patch version without critical fixes if there is a sufficiently large backlog of minor fixes, or for development snapshots (of an odd-numbered minor version). While we generally wait until there is a critical fix to release a patch version, these versions may also contain other minor fixes committed in the meantime. 5.2.1) usually reflect critical fixes, such as to security or other severe bugs. This applies only to the minor version number. 5.0, 5.2, 5.4) odd numbers are reserved for development releases. Note that official releases will always have an even-numbered minor version (e.g.

These would include additions and/or backward-compatible changes to interfaces, support for new technologies or platforms, and general improvements and fixes. 5.2) reflect smaller new features, and other nonbreaking changes. These would include major features being removed or added, interfaces being changed, significant UI changes, etc. 5.0) reflect large, visible, and/or breaking changes. These should be fixed as developer time permits, and will be included in the next scheduled release if completed. Low security bugs are issues which are hard to reproduce and only occur under some circumstance. They should be fixed as soon as possible, but will be included with the next scheduled release. These include bugs such as bug 1054702 and bug 873932. In these case, a new point release would be done as soon as possible.Ī medium security bug is a bug which could cause user harm indirectly or if some heighten level of permissions are required. Non-security bugs that could cause data loss or corruption. Along with the Mozilla Security Team, it should be determined if the issue is valid, and the severity (the sec-low, sec-moderate and sec-high keywords is normally used for this).Ī high security bug would include (but is not limited to) data leakage (including CSRF/XSS attacks) or when the exploit is already publicly available (as was the case with bug 1036213). 1.4.5 Check-In Security Bugs and Release NotesĪll security bugs should be triaged as soon as possible by the Bugzilla team.