Blocker bugs: Difference between revisions

From SambaWiki
(Add page describing blocker bugs and how they work)
 
 
(4 intermediate revisions by one other user not shown)
Line 8: Line 8:
=Bugs in Releases=
=Bugs in Releases=
==All bugs are important==
==All bugs are important==
It is vital that bugs in Samba [https://bugzilla.samba.org be reported in Bugzilla], and assigned a correct severity.
It is vital that bugs in Samba [https://bugzilla.samba.org are reported in Bugzilla], and assigned a correct severity.


==Regressions==
==Regressions==
Line 17: Line 17:


The criteria for holding back a release candidate from becoming a final release is that the bug has a '''severity''' marked as '''regression''', and is assigned the '''milestone''' the same target version as the '''release'''.
The criteria for holding back a release candidate from becoming a final release is that the bug has a '''severity''' marked as '''regression''', and is assigned the '''milestone''' the same target version as the '''release'''.

The bug must truly be a regression, that is not present in the current production release of Samba. Regressions discovered in older versions but still present in the release candidate are important, but do not count for this rule.


==Why do '''critical''' bugs not block a release?==
==Why do '''critical''' bugs not block a release?==
The Samba team cares deeply about producing new Samba versions that are not only of high quality, but on time. If an issue is important, then developers do address it as they are able, but sometimes issues are complex or maintainers are unavailable in a specific timeframe. If an issue is already present in a released version, and the upgrade doesn't make the situation any worse, blocking the release would deny new features and other fixes to other users.
The Samba team cares deeply about producing new Samba versions that are not only of high quality, but on time. If an issue is important, then developers do address it as they are able, but sometimes issues are complex or maintainers are unavailable in a specific timeframe. If an issue is already present in a released version, and the upgrade doesn't make the situation any worse, blocking the release would deny new features and unrelated fixes to other users.


=Finding release blockers=
=Finding release blockers=
Line 29: Line 31:
==Current practice==
==Current practice==
For Samba 4.4 and later the correct approach is to search bugzilla, eg with a [https://bugzilla.samba.org/buglist.cgi?bug_severity=regression&list_id=4431&query_format=advanced&target_milestone=4.4 bugzilla query for regressions] (in this case for 4.4), and a [https://bugzilla.samba.org/buglist.cgi?bug_severity=regression&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&list_id=4432&query_format=advanced&target_milestone=4.4 query for unreleased regressions].
For Samba 4.4 and later the correct approach is to search bugzilla, eg with a [https://bugzilla.samba.org/buglist.cgi?bug_severity=regression&list_id=4431&query_format=advanced&target_milestone=4.4 bugzilla query for regressions] (in this case for 4.4), and a [https://bugzilla.samba.org/buglist.cgi?bug_severity=regression&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&list_id=4432&query_format=advanced&target_milestone=4.4 query for unreleased regressions].

=Background=
See [https://lists.samba.org/archive/samba-technical/2015-May/107241.html this mailing list post] for further background, in particular on why only regressions are accepted as blockers.

Latest revision as of 09:28, 4 August 2016

This page seeks to describe the Samba Team's policy for blocking the release of a Samba version, in particular a new major release.

Time based releases

As Samba is developed on a time-based release policy, missing or incomplete features will not cause a release to be delayed.

It follows that features being landed in master should be landed in a way that moves the project forward, ideally be built of smaller parts that are useful and complete in their own right, and not be enabled by default until they are ready for use.

Bugs in Releases

All bugs are important

It is vital that bugs in Samba are reported in Bugzilla, and assigned a correct severity.

Regressions

Regressions, that is bugs that are present in new versions of Samba, in existing features, that are not present in older versions, are very important to the Samba Team and are addressed as a priority.

Blocking Major releases

The criteria for holding back a release candidate from becoming a final release is that the bug has a severity marked as regression, and is assigned the milestone the same target version as the release.

The bug must truly be a regression, that is not present in the current production release of Samba. Regressions discovered in older versions but still present in the release candidate are important, but do not count for this rule.

Why do critical bugs not block a release?

The Samba team cares deeply about producing new Samba versions that are not only of high quality, but on time. If an issue is important, then developers do address it as they are able, but sometimes issues are complex or maintainers are unavailable in a specific timeframe. If an issue is already present in a released version, and the upgrade doesn't make the situation any worse, blocking the release would deny new features and unrelated fixes to other users.

Finding release blockers

Historically

In older Samba versions, we used a single 'blocker bug' often like the release blocker for 4.2. In these releases, the bugs were managed by bug links.

This practice ended with release 4.3.

Current practice

For Samba 4.4 and later the correct approach is to search bugzilla, eg with a bugzilla query for regressions (in this case for 4.4), and a query for unreleased regressions.

Background

See this mailing list post for further background, in particular on why only regressions are accepted as blockers.