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

[Mark]

On Thu, Jun 21, 2012 at 4:44 PM, Jeremy Whiting <jpwhiting at kde.org> wrote:
> On Thu, Jun 21, 2012 at 8:13 AM, Mark <markg85 at gmail.com> wrote:
>> On Thu, Jun 21, 2012 at 11:20 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
>>> On Wednesday, June 20, 2012 22:15:35 Mark wrote:
>>>> To me the definition of a regression is as follows:
>>>> A regression is an issue that wasn't in the previous release.
>>>
>>> that would describe all new bugs ;)
>>>
>>> a regression is something that worked properly (for whatever that means in the
>>> given situation) in a previous release and then ceased to do so.
>>>
>>>> Things get a bit more complicated with adding the "release_blocker"
>>>> keyword. When do you add that keyword to a bug?
>>>
>>> data loss, a bug that renders the entire application unusable for the intended
>>> primary use cases, .. it's a very serious situation.
>>>
>>> if in doubt -> ask on the list.
>>>
>>>> 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.
>>>
>>> this is not a release blocker. why? because:
>>>
>>> * it is an optional component, critical to neither the use of kget nor plasma
>>> desktop
>>>
>>> * it does not cause data loss
>>>
>>> * it does not render the system generally inoperable
>>>
>>> it is a rendering issue. it's also a component that ships with kget and
>>> maintained by the kget developers so it should be assigned to kget in bugzilla
>>> (already done this).
>>>
>>> it is not, however, a release blocker. it's something the kget developers, or
>>> someone who feels motivated to help them out :), need to fix.
>>>
>>>> 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.
>>>
>>> not when they are this minor, no.
>>
>> True and i completely agree with it.
>> But this doesn't make it any easier. Marco said (above): "i don't
>> think we should make releases with random pieces cutted out, or they
>> will never be complete" so we don't cut out pieces that don't work yet
>> we also don't want to release pieces that don't work.
>
> Nobody said we don't want to release pieces that don't work.  We do
> release pieces that don't work.  Then those bugs are much more visible
> and developers (hopefully) have more motivation to fix them. :)
>
> Just my 2c,
> Jeremy
>

Ehhh, that's a very strange reasoning :p That way you could release a
completely broken KDE SC (like KDE 4.0 was ;p) then developers will
certainly be motivated to fix it asap. That is bad publicity for KDE
and a bad KDE image that you should never want to have.