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

[Mark]

On Thu, Jun 21, 2012 at 5:18 PM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> On Thursday 21 June 2012 16:56:51 Marco Martin wrote:
>> On Thursday 21 June 2012, Mark wrote:
>> > >> 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.
>> >
>> > If you follow that reasoning it is... a blocker :p
>>
>> sometimes we just have to release with known issues or release never.
> +1
>
> we cannot reach 0 bugs, it's impossible. So we have to compromise. For minor
> issues it is valid to say that can go into the release.
>

I agree, no issue about that :)

You guys talk around the issue a bit though. I'm talking about what we
- as in the "floating devs" that dev for random things and sometimes
do a bunch of bug triaging - should do for components that don't
directly influence KDE.

(from a few posts back)
To phrase it more clearly.
How do we deal with individual components that are completely broken?
How do we mark such issues in bugzilla? And how does the release team
handle those issues if they are still completely broken once a new KDE
SC is about to be released? (not a beta or rc, but final release)