[Release Planning 3.4] v3-4-test will be frozen tomorrow

[Henrik Nordstrom]

mån 2009-10-19 klockan 09:18 +0200 skrev Karolin Seeger:

> Due to our new policy proposed by Jeremy, we should delay 3.4.3 until the
> blockers are fixed or severity has been lowered. Others suggested that
> blockers should not block a bug fix release.

That discussion is more about what is to be considered a release blocker
than ignoring the bugs currently assigned status in bugzilla, and the
bad effects of having a blocker open for too long.

What imho is a blocker and how to deal with them:

 - It it a security issue? Yes. But may still be kicked forward if takes
time and blocking getting other security or regression fixes out.

 - Is it a regression? Yes, unless the affected feature is experimental
and clearly marked not for production use.

 - Is it otherwise a very important bug in the view of the project?
Maybe, but should be kicked forward if other bug fixes already motivate
a bug fix release if this blocker is ignored.

 - New feature or new OS compatibility? Then it should not be a blocker
for a bug fix release. For a new release yes, but not for a bug fix
release. May still be a critical bug, but not a blocker for bug fix
release.

 - Only hitting uncommon setups or acceptable configuration workaround
available? Not a blocker.

Most are obvious, just that from time to time it's important to review
the list of already included bug fixes weighted to the list of open
blockers to evaluate if the blockers really need to block those bug
fixes getting released or if the blockers should be kicked forward to
the next bug fix release or even downgraded to non-blockers (if
something gets kicked forward more than once then it's probably not
rightfully a blocker)

The blocker status is some times misused as a priority setting, which
isn't the right way of using the blocker status as it then messes with
release planning in ways it should not.

Regards
Henrik