When should a bug be considered as a regression or a release_blocker?

[Mark]

Hi,

Yesterday i was looking over quite a few plasma bugs and noticed a lot
of bug being filled at the new QML components.
I marked most of them as regressions since they looked like regressions to me.

To me the definition of a regression is as follows:
A regression is an issue that wasn't in the previous release.

Things get a bit more complicated with adding the "release_blocker"
keyword. When do you add that keyword to a bug?
Thus far i considered a bug a "release_blocker" if the issue means
that the item is unusable or causing loss of data. For example
https://bugs.kde.org/show_bug.cgi?id=301854. It's a very innocent
plasmoid, but it's unusable on multiscreen environments thus i marked
it as a release blocker. Another example is
https://bugs.kde.org/show_bug.cgi?id=301854, that bug described the
KGet Piechart applet as being broken. I tested that and verified that
it indeed is completely broken and even renders outside it's applet
space. So i marked that one as release blocker as well because it's
useless in it's current state.

Both issues are not something that obstruct normal KDE usage, but they
do render some parts of KDE completely useless. I'm a bit unsure if i
should mark such bugs as release blockers. Perhaps there should be a
keyword called "component_blocker" indicating that a specific
component (specified in the component field on bugzilla) is not fit to
be shipped with the release.

I would like to have some clarification on when something should be
marked as a release blocker. So perhaps we can draft up a general
guideline for the conditions that justify a bug being marked as
release_blocker.

Kind regards,
Mark