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

[Martin Gräßlin]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120620/742dd199/attachment.sig>