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

[Mark]

On Wed, Jun 20, 2012 at 10:50 PM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> On Wednesday 20 June 2012 22:15:35 Mark wrote:
>> 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.
> yes, that's how I consider a regression. A bug introduced by a code change in
> the recent version.
>>
>> 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.
> I am very careful about using the release_blocker keyword. We have to properly
> judge it. If we add a release_blocker we consider the issue that strong that
> it would block all of KDE SC.
>
> Given that I consider only very severe issues a release blocker, such as data
> loss or severe damage to the system. Any non-default component cannot be a
> blocker in my opinion.
>
> For 4.10 I set one bug to release_blocker in KWin and that was the bug to
> track the writing of the kconf update script. I considered not having a
> migration as an issue severe enough to say that we cannot release without it.
>
> Cheers
> Martin

I completely agree with you, but that still leaves broken parts of KDE
SC. I mean, you obviously can't release them since they are broken so
if you follow that logic they block the release or they just don't end
up in the release. Both options aren't very attractive. So what do we
need to do with broken parts of KDE SC even though they don't
interrupt normal KDE usage?